Skip to main content

A failed Sprint Review

Do your sprints look anything like this:
  • In Sprint Planning 1, the team commits to implementing 8 stories and fixing 2 bugs (open issues identified in the previous Sprint Review).
  • During the week -- our sprints last one week -- from the Product Owner's perspective, everything seems very quiet. The virtual task board is showing no movement. No builds are forthcoming. No calls or questions either.
  • Friday before the Sprint Review there is some pickup of activity. 
  • Monday, 1 hour before the Sprint Review, a build becomes available. Theoretically, everything is done. You download the build. Start to test the functions. Crash. Try again. Another crash. Hmm. What can I test without causing a crash?
  • In the Sprint Review - we go through the 10 stories and bugs. The Review lasted 2 1/2 hours for a one week sprint.  The bugs had been fixed. 2 of the 6 stories were implemented and are done. The remaining 4 stories were not done and had to go back on the backlog (and yes, I did put them into the next sprint). The new crashes also came into the backlog.
This had been our pattern for the last several weeks. As Product Owner for this project, I found this very frustrating. Particularly because I had been asking for continuous delivery for several sprints, but the team still wasn't doing it. As a Scrum Trainer, I found it very embarrassing to be having problems with getting things done. My team was embarrassed too. They are a good team. We're better than this. How did we get into this trap? More importantly how do we get out?

Step 1 is listening. (see From a Blame Culture to Fearless Trust) I believe that when people really listen to each other, great things can happen. My personal challenge was putting away my frustration so we could listen and discuss effectively. Juliano and I sat down on Skype and Hangout and talked and listened to each other. We identified several things:
  1. I was concerned that I was doing too much of the thinking about how to solve the problems.
  2. Juliano felt the giving the team responsibility for creating the the how-to-demo section had been a good thing, as it encouraged them to really think about the issues.
  3. Our definition of Done has included continuous integration with a Jenkins build since the beginning of our project, but for many reasons, we had not actually implemented it. So creating and publishing a build was a lot of work. (see Sample Definition of Done )
  4. The team was doing overtime every sprint.
  5. The team felt pressure to deliver as many stories as possible, so they were committing to the maximum they could. As a result, they had no time to work on quality issues, like setting up build server or responding to feedback if it arrived during the sprint.
  6. The definition of Done was being applied at the Sprint level, not to each individual story. So all the stories were getting delivered shortly before the end of the sprint without any time for feedback.  (see It's Done! (or is it?) ) 
Particularly these last two items were causing the long Sprint Reviews. After discussing these points, we agreed to emphasize quality over quantity. So now we had a shared commitment that getting some things really done is more important than getting everything sort-of "done."

As a result, we put one new item in the Product Backlog.
"As Product Owner, I would like a new build when every feature is completed, so I can confirm that stories are really done as soon as possible."
We prioritized this as number 1 for the next sprint, even higher than unfinished work from the previous sprint. The team focused on getting the build server working, then on getting stories done one after the other, and in the order prioritized. They also reviewed the definition of Done, and how they could better ensure that things were really done.

As I write this, tomorrow is the Sprint review, so this is a work in progress. Some changes are already visible:

  1. The features have been coming one by one, which makes it easier to review them and give feedback. The team delivered three releases, probably another one will come before the review. So we have quadrupled our output of potentially releasable software.
  2. We discover problems quicker on the way to Done - "hey, this story has no 'how-to-demo' defined. How do we know if it works?" or "This doesn't install on my iPad 4."
  3. We are thinking much harder about how to ensure that stories are really Done. We use TargetProcess to manage our work, so we are exploring how to use the test suite and task creation plugins to automate the routine parts of identifying what has to happen to get a story to done.
  4. The quality of the delivered stories has gotten much better. It seems taking off the pressure to deliver quantity enables the team to do better.
Is really Done functionality being produced on every story and on every release? Has the team gotten faster? Is this approach sustainable? Let's say, we still need to do retrospectives, there is still room for improvement, and for some questions, only time will tell. But as Product Owner, I am really pleased with what have I seen up til now, and look forward to the Sprint Review with a smile.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…