Handling stories with blocking business issues
One of our teams that is undergoing the transformation towards Scrum came across an interesting situation:
- A Sprint, and all its stories have completed all development, testing, acceptance, sign-off, product owner acceptance, etc…
- One Story in the Sprint cannot be released with the Release – because there’s a dependency on the business to have completed end-user training, which the business needs a few more weeks to do.
So how would you handle this?
- Approach 1: Story does not meet the definition of done.
- The training item should have been a task for the story in order to satisfy the goal of potentially shippable.
- Since a dependency/condition to being shippable was not met, it’s not done.
- Thus the Story would be pulled out of the Sprint and moved back into the backlog or into the next Sprint if it still has value and released on the next Release.
- It would cause a dip in points and artificially drop the velocity for that Sprint (all the work by the team was satisfied, there’s no more work to do), but that dip is ok as it points out an issue that prevented value from being delivered.
- Approach 2: Business issues should not affect velocity.
- The team completed all work needed to create releasable code – the velocity should be recognized.
- If you keep the Story in the Sprint, it would delay the Release… for weeks. Which is the prerogative of the business. However it’s not a few days of delay, it would bump up against the timing of the subsequent release which goes against the mantra of continuous value… value is not created until you release it.
- Alternatively, you could ‘complete’ the story to record the velocity, but create a placeholder in another Sprint to recognize it actually being released. Or replace a faux/filler story just for velocity tracking purposes, and move the real story into the real Sprint/Release that it’ll get released in.
Taking a step back from terminology and thinking just pure process wise – if a Story can’t move forward for whatever reason, to keep it simple, it gets pulled from the Sprint.
It will cause a dip. Which on one hand is artificial in that the team did actually produce those points. However POs & SMs will want to know & track these hiccups, understand why it occurred, and work to minimize these impediments to releasing value.
We’d still know the real velocity from a planning perspective. But one of the strengths of Scrum is that it flushes out issues quickly and clearly. Which is good, because the only way for issues to get resolved is to get them out on the table, which is far more important than masking issues in order to make a burn down look the way you want.
Thoughts & suggestions welcome!
Leave a Comment