Looks like we will start a new series because today again I would like to write about something that relates to the question received from one of our users. Let’s take a look at story acceptance process.
So there comes the day when you demo your product and a product owner shall accept stories after just closing iteration. We’ve implemented a quite simple and intuitive way of accepting or rejecting stories in tinyPM.
Basically, as a Product Owner, you can do two things for each story that has all its tasks completed:
- Accept the story – which simply marks it as accepted.
- Reject the story – which will also mark the story as rejected, but in addition to that you need to provide a reason for rejecting the story. This description will become a new task within the rejected story.
And here the story begins… What should happen now with such a story? Due to added task the rejected story goes back to “in progress” state because not all tasks has been completed. In other words, by rejecting the story we add more work to be done to finish story correctly.
But it’s the end of the sprint. This leaves basically two choices (well maybe three but the 3rd one is a bit unlikely):
- You move the whole story to the next iteration. Yes, sorry, it’s not done done and you loose velocity.
- You leave the story accepted, create another story like “Minor/non-blocking bugs from previous iteration” and move the task there. This way the story will have all tasks finished again and it’s possible to leave it accepted where it is now (you may add a comment to the story to give at least some trace of the bug there).
But even if the 2nd solution may sound tempting, I would call it a project smell in the long run because you may find yourself moving many tasks this way. It will result in violating Definition of Done and cheating on velocity which will most likely stay intact. I wrote about it once in “Shall I Split My Stories? Yes… I Mean No!”
I’ve mentioned the 3rd option, so here it is (but rather unlikely). If it’s really a minor bug and you have still some time in the iteration, you may fix it (for example the same day) and still get the story accepted.
I would rather opt for the 1st solution as it may actually reveal the root problem if you will notice loosing velocity in such a way a few times more. Maybe you overcommit in the first place and then need to cut corners. Or maybe you should work on improving communication with your PO during the sprint to learn what may be wrong with your stories earlier. This way when it comes to the final demo most of the stories will get accepted as they meet the PO’s expectations better.
And which way do you choose most of the time?