All About Agile | Agile Development Made Easy!
Definition of Done vs. A blocking business issue
We've come across an interesting scenario.
- A Sprint, and all its stories have completed all development, testing, acceptance, sign-off, product owner acceptance, etc...
- One story however, cannot be released with the Release - because there's a dependency on the business to have completed end-user training, which they didn't line up timing wise properly.
- It will take 4 more weeks for this training to occur.
So how would you handle this?
- Does it not satisfy done, as that Training item should have been a task for the story in order to satisfy potentially shippable?
- Thus it would be pulled out of the sprint and moved back into the backlog or into the next sprint - it would cause a dip in points and artificially drop the velocity for that sprint, but that dip is ok as it points out an issue that prevented value from being delivered.
- The other perspective is based on the rule of thumb that business issues should not affect velocity.
- It's not the team's fault that the business didn't time training right.
- But, if you keep the story in the sprint, it could delay the release of the Sprint - which goes against the mantra of continuous value... value is not created until you release it.
- Or 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.
Views: 70
Replies to This Discussion
-
Permalink Reply by sachinkundu on -
What you have is an impediment.
Impediments are to be noted. Displayed prominently and rigorously followed up.
The team does not claim velocity out of it because it was never delivered, but it does move on to do other work.
Its very important to not have us versus they, because nothing is useful unless shipped. Unclaimed velocity signifies what needs to be improved. Raise the issues higher up where bottlenecks in the production chains can be managed better, and additional buffers places so at to minimize work in progress
-
Permalink Reply by Tariq Ahmed on -
Thanks Sachin, that's a good perspective.
Though you imply that velocity is based on 'delivered' stories. From what I've seen, it's all about potentially shippable software vs. shipped software.
-
Permalink Reply by sachinkundu on
-
Its where your organisation draws the line. I am a fan of shipped software, not just potential but that depends on context.
Anyways the important point being move on with development and follow up on the impediment. That should do it
-
Permalink Reply by Andrew Baxter on -
To me this is about "Definition of Done". If the your acceptance criteria for the user story is to complete "user training" then I would consider not starting the user story until you can be sure that you can align with your dependency. If possible I would like to have the people conducting the end-user training included in the sprint planning meeting and preferably embedded with the scrum team.
Alternatively, remove the "user training" from the DoD. Your team is "done". The other team responsible for end-user training is not "done".
If new user stories arise from the user training, so be it. Add them to your backlog and iterate again.
© 2012 Created by Kelly Waters.
