We must have working software at the end of the Sprint!

This is a common failing (we don’t have working product or working software at the end of the sprint).  Jeff Sutherland has said this is the biggest problem in the Scrum community — too many teams don’t have working software at the end of every Sprint.

If we include cases where 1 or more PBIs (Product Backlog Items) or stories are not completed, this is a very big problem, and very common. So, how do we fix it?

The root causes at your place or your friend’s place may be very different from mine.  Here are some likely areas to look.

1. A better definition of done.

First, have one, have a definition of done.

Second, let it actually be what people are committed to doing (rather than just some pretty words on the wall).

Third, put the DOD in a process format rather than an “end-state” format. Show how the team will get to done.

To me, a minimum definition of done for a software product includes the following:

Requirements (of course)
Coding (of course)
Unit Testing (typically by the coder), automated.
Functional Testing (by a qualified professional tester, of the functionality in that PBI, at least, and most tests are automated)
Product Owner Review (ie, the PO likes it, once a story is ‘complete’).
And all bugs or problems are fixed, and re-tested.

This is the minimum, IMO.

2. Your testers are used to slow manual, non-agile, testing.

They may not say it out loud, but they don’t really understand agile. They are still expecting to do it the old, waterfall way.

3. Lack of good automated testing, and automated testing frameworks.

This could include a lack of people who understand automated testing, why it is needed, and how to do it well.

4. Smaller stories.

It is very common not to complete stories if one or more stories (or PBIs) are too big.  One rule of thumb: If the Sprint is two weeks (10 business days), then any story that takes more than 5 ideal person days of effort is too big.  The average story should be in the 2.5 ideal person days range. Total for all people working on that story.  Put another way, I want at least 8 stories in each 2 week Sprint. All about the same size.

5. The Team is over-committing in Sprint Planning Meeting (or being over-committed later).

This is very common.  They should not take on more work than they can do. Period.

6. The Team does not understand well-enough why working software at the end of the Sprint is important.

Often, they forgot.  They knew 3 months ago (when the trainer told them and they agreed), but they have forgotten since then.  Not all of them, but maybe most of them.

***

Often they will admit to one of the 6 root causes above (or some others), but they won’t put much energy into fixing it or them, since they don’t really agree that the problem is all that important.

***

We must have working software.

If you can identify the problem, the root cause, usually you are more than half-way to fixing it.

More on the fixes to these problems later….

 

« « Business Value Engineering framework || More on: The Product Owner and the Team » »