Comment: Changes to work forms an interesting tension.  At a fine grained detailed level it changes all the time. Each person’s individual to-dos often change to reflect their understanding of what it takes to get the job done. As the level of granularity increases to task then it is a change to the team’s plan. If the number of changes is significant and adds up to more than one story’s worth of work then you better stop and adjust your plan, usually you want the product owner in on that discussion. And if there are several new  stories that were  suddenly found and are so important they must be done right now, then call a stop and reset your entire sprint with a sprint planning session. Generally, the commitment by the team to the sprint should not change. Note: definition of team makes this an interesting discussion. Bottom Line: The goal here is to help the team get better at  expressing work they can do and following through on a commitment.

Attached is our latest chapter Scrum In A Nutshell.

This version is baked and we would love your feedback.

Please download and read.

The tasks for a story are “owned” by the team; the team commits to stories, not tasks. The tasks only exist to aid the team in its development efforts – it is the “doneness” criteria that define the “contract” for the story, not the tasks. Generally speaking, it is nobody’s concern except the team’s who works on what task, or even what the tasks are.

In general, a story is simply a request for the team to do something of value. This does not mean releasable value; that’s what capabilities are for. It does mean demonstrable, testable, verifiable value, as we need to be able to be able to inspect and adapt based on the results.

A story is an extension of the user story, which was introduced in eXtreme Programming (XP), but we don’t restrict stories in scrum the just the ones that user value. This is why we just call them “stories”, and often add a modifier, like “analysis story” or “infrastructure story” or “development story”.

In spite of the fact that not all our stories are user stories, it is useful to look at the INVEST acronym, which Bill Wake originally introduced to describe “good” user stories:

While the acronym needs to twist a little bit to fit when we expand the concept from “user story” to just plain “story”, the basic ideas are good. Basically, a good story is one that is small and well-understood enough for the team to commit to and not be confused by. If we are talking about functional stories, the definition of “small” the I like to use is “one thread” or “one positive test” or “one state of the system” or something like that. We’ll discuss this concept in the next chapter, when we discuss the definition of “done.”

The concept of the story is both simple and brilliant. What makes it simple is that at its core a story is just a request for something of value, and the purpose of the story is to start a conversation.  The story takes the place of a requirement, but it has a completely different tone.  Whereas the requirement has the tone “here’s what I want, just go do it” the story has the tone “here’s what I want, let’s talk”. As Alistair Cockburn has said “a story is a promise for a conversation”.

What makes a story brilliant is that not only does it replace a requirement, it also replaces the low-level activity; a story is not only the request for value, it is also the activity, or work, that it will take to provide the value.  In practice, this means that as you are doing analysis in order to find requirements/stories you are also developing your units of work.  All you have to do is add prioritization, and you’re good to go – your planning is done. Some examples of stories include:

•         “As a <passenger>, I want to <be able to select my seat online>, so that <I don’t have to do it at the airport>”;

•         “Go talk to the pilots and find out what they think about pilot compensation”;

•         “Review the suggestions the pilots have submitted to see if there’s anything cool there”; or

•         “I need somebody to spend an afternoon with the pilots, to explain to them how the pilot compensation page works”.

There are other things we want from our stories, as well, and we’ll be discussing them throughout this book. For now, though, this is enough.

(Scrum I, Early Scrum, 1995-2004-ish) PO usually external to team, negotiates sprint backlog with the team. The team self-organizes, produces “done” product, and has a Sprint Review with the PO, who either approves or disapproves the work. The only way to “officially” change requirements in the middle of the sprint is to have an abnormal termination and start over. After the sprint the team (sometimes including the PO) has a retrospective to improve its process, and the PO modifies the release plan.

This leads to a number of Issues/Forces:
 - adapting to business changes within the sprint is difficult
 - hard to talk to PO for additional guidance during the sprint
 - often caused the team to view the PO as “one of them” and not “one of us”
 - many teams created a “Product Owner Proxy” who represented the PO day-to-day on the team

(Scrum II, Modern Scrum, 2002-Present) PO internal to team, and negotiates sprint backlog with rest of team. The team (including the PO) self-organizes, produces “done” product that is accepted by the PO along the way. Teams develop various methods for reprioritizing and bringing in new work during a sprint (negotiating techniques, mid-sprint replanning, etc). The Team (including PO) reviews the results with external stakeholders during the Sprint Review and receives feedback that changes the release plan and is incorporated into the next sprint’s planning. After the sprint the team (including the PO) has a retrospective to improve its process.

Differences:
 - PO on team
 - more in-the-sprint changes to Sprint Backlog
 - PO is more a part of the team’s day to day work
 - Adaptive Evolution of the Product is finer grained
 - Focus on delivery to Stakeholders, not PO

There were/are some Issues/Forces:
 - Still not quite adaptive enough for some
 - “last few” stories on sprint backlog are always being supplanted by new ones
 - Sprint lengths got shorter to allow for more frequent feedback and planning
 - can’t make the sprints as short as we’d like to because some stories just “take that long”

(Scrum III (KanBan-ish version), 2007-Present) There is no Sprint Backlog, only Work In Progress (WIP), which is fixed length set of stories currently being worked on. There is still a Sprint, which is a fixed-length timebox that defines the time between reviews, the changes to release planning, and the setting of sprint goals. At the beginning of the sprint the Product Owner negotiates goals for the sprint with the team. The team is constantly grooming and reprioritizing the backlog. When a story is completed, a new one is moved up to the WIP and begun. At the end of the Sprint there is a Sprint Review for the Stakeholders where the completed work is reviewed.

Differences:
 - Sprint Backlog replaced by WIP
 - because is WIP, stories can go across sprint boundaries

Note that this evolutionary change is much smaller than the former. Perhaps we are converging on a final solution – I don’t know. I have no idea what comes after this. We’ll just have to wait and see what issues come up, and what patterns emerge.

Dan  

Here is round 2.

This is close to a done draft.

Please read and comment.

                                               Scrum In A Nutshell – Quick Summary

* Coded – it works on the developer’s box
* Verified – Unit tested and they work on Integration box
* Validated – accepted by ProductOwner as being what was needed

Later on a fourth “Done” was added for “Production Ready”, which meant:

* Production Ready – all additional stuff was there, like
documentation, training for users, etc

Now, I still like the four “dones”, but have a slightly different focus.
Since Stories are now well-defined bits of work, with well-defined
definitions of done, there is no longer the subjective third “done” for
them. The Product Owner no longer gets to decide if it is what is
needed, the story is defined to be done once the acceptance criteria are
verified. So there is not a hierarchy of things we do:

* Stories get “Done/Done”
* Features get “Done/Done/Done”, and we don’t know how many stories
this will take
* Products get “Done/Done/Done/Done”, and we don’t know which
features this will take, or how many stories it will take

This new way of looking at things shows us what is really going on.
Within the team’s work there is only tactical agility, where the team is
being agile in figuring out how to meet its story’s acceptance criteria.
There is low-level strategic agility where the PO is deciding which
stories to deliver for each feature in order to provide the value (for
that feature) that is needed. And there is high-level agility where the
PO is deciding what is the “releasable feature set” necessary to
actually be able to put this thing into production. Three different
levels of agility, three different sets of stakeholders, three different
levels of abstraction and questions to ask.

Dan Rawsthorne
dan@danube.com

• Are your sprints time-boxed to less than 4 weeks?
     Very good teams can vary the length from sprint to sprint but, only do so when the product has a clear and compelling need. Exceeding 4 weeks is just a bad idea for people since our memories are not the good. Your efforts can always be broken down to 4 weeks or less and it is always worth the effort to do so. If it is 5 weeks then to 4 weeks and 1 week or some patter like that but, keep it time boxed and less than a month.
• Have software features been tested and shown to be working at the end of each sprint?
     It is so easy to call something done that is not quite done. Finishing is a challenge. Great teams and excellent products are built by those teams that develop an ability to finish. 
• Are you causing paralysis by over analyzing instead of moving?
     When you find an opportunity to proceed you should move. Great teams avoid analysis paralysis by moving when the opportunity presents itself. Even if nothing is clear movement in any direction will reveal more information about the problem.
• Is there a product owner available to answer questions and prioritize?
     When this position is vacant or absent the team’s movements are erratic and often in the wrong direction. Moral becomes an issue and quality suffers.
• Is a product backlog prioritized by business value?
     Teams will work on what seems important to them first. Even if it is not what the business needs next. No surprises there. Without an engaged product owner the needs fo the product are not championed and efforts are often mis applied.
• Does your team create estimates for items in the sprint backlog?
     Your team should own the estimates in the sprint backlog the product owner should budget for items in the product backlog. Read Dan’s work on estimating vs. budgeting to clarify this concept.
• Does the team express their work so that a burn-down chart can be created?
• Does the team know their velocity?
• Are others like project managers (or anyone else) disrupting the work of the team?

The Nokia test is broken down into two parts. Often we see teams doing the 1st part but, not the second.

Part I: Test for iterative development:

• Iterations must be timeboxed to less than 4 weeks
• Software features must be tested and working at the end of each iteration
• The Iteration must start before specification is complete

Part II: The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

• You know who the product owner is
• There is a product backlog prioritized by business value
• The product backlog has estimates created by the team
• The team generates burndown charts and knows their velocity
• There are no project managers (or anyone else) disrupting the work of the team

I first heard of this test from Bas Vodde who worked at Nokia to develop this test.

Thank you

Dan & Doug