This is a common failing (not enough working software). Jeff Sutherland has said this is the biggest problem in the Scrum community, that too many teams don't have working software at the end of every Sprint.
If we include cases where 1or 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?
Well, the root causes at your place or your friend's place may be very different from mine. But here are some likely suggestions.
1. A better definition of done.
First, have one. Second, let it actually be what people are committed to doing (rather than just some pretty words on the wall). Third, put 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), and Functional Testing (by a qualified professional tester, of the functionality in that PBI, at least), and Product Owner Review (ie, the PO likes it once '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 of 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. And 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), but they have forgotten since then. Not all of them, but maybe most of them.
Often they will admit to one of the 1-5 root causes (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.
***
Well, 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....
If we include cases where 1or 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?
Well, the root causes at your place or your friend's place may be very different from mine. But here are some likely suggestions.
1. A better definition of done.
First, have one. Second, let it actually be what people are committed to doing (rather than just some pretty words on the wall). Third, put 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), and Functional Testing (by a qualified professional tester, of the functionality in that PBI, at least), and Product Owner Review (ie, the PO likes it once '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 of 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. And 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), but they have forgotten since then. Not all of them, but maybe most of them.
Often they will admit to one of the 1-5 root causes (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.
***
Well, 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....
No comments:
Post a Comment