Yesterday at BAR (Brighton Agile Roundtable) I commented to Chet that I wasn’t doing any work on The Increment, the book I’m allegedly working on. In the course of that, we started talking about the Sprint Goal, which of course defines what’s supposed to go into the Increment. You’d think they’d go hand in hand.

It seems that the default form of Scrum On The Ground is that the Product Owner [Delegate] brings in a bunch of stories, and the Sprint Goal is “get these done”. Frankly, this is pretty weak Scrum: it leaves very little room for harnessing the creativity of the Dev Team. Let’s think about that.

Mary Poppendieck, of Lean Software Development fame, has a number of objections to Scrum. One of them is that she feels that Scrum does not properly capitalize on the creativity of the team, leaving too much authority in the hands of the Product Owner. In fact, she prefers the term Product Champion (as do I), emphasizing that their job is to support the team, and guide them, but that the team should own responsibility for the product.

My position over time on this has been “Yes, and that’s what Scrum really expects you to do,” pointing to Backlog Refinement as a place where PO and team come together to figure out what to do, and to the Sprint Review, where we look to the future with stakeholders, and to Sprint Planning, where the team is supposed to figure out what the work is that is actually to be done. All these things, properly understood, vest “how to do it” in the team, with “what to do” being vested in what Scrum calls the Product Owner.

However, the more the Product Owner brings in detailed stories, the less the team is able to creatively produce solutions to the real needs. This is the point of the Sprint Goal, as I see it: allowing plenty of room for creative solutions. Let’s look at two ways of approaching the same problem, a typical Internet shopping site.

Detailed Stories

In our first scenario, the Product Owner sits down with a business analyst and a UX expert, and they draw up a detailed work flow for customers to buy things, with screens for products, shopping cart, credit card and personal information entry, and so on. We all know the drill: this is yet another shopping app.

In this scenario, all too typical, there’s little or no room for the team to get creative. Even if they do have some great ideas, the PO and BA and UXer have already set their minds on what’s “needed”, and they’ll find it very difficult to entertain a new and better way, be it grand or small.

There may not even be much room for slicing the stories down, because having worked it all out, the natural inclination of the Product Owner will be to say “I need it all”, when faced with a suggestion that something be deferred.

While the Product Owner may have a “theme” in mind: “This Sprint we’ll be working on updating the Cart”, there’s still not much room for creativity if they go on to say “and here are the UX diagrams for the changes I want”.

Goals and Themes

Suppose, instead, that the Product Champion has a backlog consisting of items like:

  • Ordering products
  • Keeping track of personal information
  • Credit card management
  • Saving items for later ordering
  • Payment and shipping

Early on, she meets with the team during Backlog Refinement and Sprint Planning and they talk about the overall flow. They collaborate to figure out some top-to-bottom simple solution to the whole idea. Maybe they propose one like this:

  • There’s one customer, Joe Smith;
  • He lives at 1234 Main St, Anytown, MI, USA
  • He has a credit card, number 0000 0000 0000 0000;
  • We only have one product, the White Album;
  • Joe wants it;
  • There’s a simple GUI, where Joe clicks “OK”, and …
    • We fake a check to authorize his card and it authorizes;
    • We print a simple fake packing slip to ship the White Album to him;
    • We print a simple fake charge to the card;
    • We call it done.

Such a thing could easily be built in one Sprint, quite possibly in one day. The team would run with this skeleton and do as much as they can during the Sprint. Over upcoming Sprints, the Product Champion might say

This Sprint, I’d like to focus on building up some kind of “wish list” for items that the customer has viewed and saved for later. We might also want to notice frequently viewed items and add them to the list, or a separate list, I don’t know, for their convenience.

The team has plenty of room to get creative here, and to extend the goal as far as they feel they can reach, or scale it back to something they can accomplish. The whole team is collaborating in moving forward, under the leadership and guidance of the Product Champion.

This is better, because it allows the wisdom and knowledge of the team to be fully exercised, and because it keeps focus on “what” is needed more than on just how it is to be done.

This is what Scrum really has in mind, I believe. Doing Scrum in this way addresses Mary Poppendieck’s concerns about product “ownership” to a large degree. More importantly, it will almost certainly be a lot more productive and result in a better product.


Focus on the broad goal of the Sprint. Derive stories from that. Use the full creativity of the team, not just of a few.