Here’s the dilemma: Your Scrum team is nearing the end of a Sprint or a release cycle and they have experienced some unforeseen problems. Completing all the planned items appears unlikely. The final build will be deployed for end-user testing so there will be plenty of attention and feedback. You’re left with two choices:
- Rush to completion. Have the team work extra hours, cut some corners, relax your definition of done, and race to the finish line.
- Return a few stories to the backlog. Stabilize what you have and deliver good-quality results.
Which should you choose?
The answer is the often used “it depends”. It depends on the situation and what is most important to the business. This is one situation where the opinion of the Product Owner matters greatly.
All stories are not created equal. Regardless of the effort needed to implement them, stories have greater or lessor value to the business. That’s why they must be prioritized by the Product Owner. The team should be working on the high priority ones first. If they’ve done that and found themselves in the above situation, it’s easier to return low priority stories to the backlog.
If they haven’t prioritized, the decision gets much tougher and some long days are in their future. Either way, there is a significant downside.
- If the release is rushed and quality suffers, the users will get a bad impression of the software. If this will be the first time they use the software, things could get ugly. You know what they say about first impressions! It could take multiple additional releases to erase that memory.
- If features are left out, some users will be unhappy. They may refuse to do any testing because the software is not ready. A credibility gap is created simply because user expectations have not been met. Credibility gaps are very hard to fill!
Often, the developers and testers have little sensitivity to this type of issue. They’ve worked hard. They’ve accomplished a lot. Why is this such a big deal? That’s why it’s important to get everyone to make personal commitments, communicate often, and ask for help at the first sign of trouble.
You cannot entirely avoid this dilemma but you can take steps to mitigate it.
- Do not over commit. When in doubt, leave it out!
- Monitor your sprint deliveries carefully using burndowns. If you fall behind, odds are you will fall further behind. Catching up is hard to do!
- When you sense trouble, communicate. Let someone know. The earlier everyone knows, the simpler it is to take corrective action. Scrum Managers and Product Owners always appreciate an early warning!
Sounds obvious, right? So why do so many software development teams get into trouble? What does your Scrum team do to avoid trouble and meet commitments?
Vin,
Any project without schedule and cost margin is late and over budget before it starts. The missing element of Scrum is the understanding that margin is needed for all thing “project.”