Dude Where Is My Feature?

Marcin Niebudek

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:

  1. Accept the story – which simply marks it as accepted.
  2. 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):

  1. You move the whole story to the next iteration. Yes, sorry, it’s not done done and you loose velocity.
  2. 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?


2 comments

  1. Chris R. Chapman -

    +1 on the first option, but I’d add a caveat: If the reason for the rejection of the story is due to information that the PO has received and is of such a nature as to invalidate the premises it was created against, then the story/feature dies and a new one should be created in its place.

    Part of the work to implement the new feature may include tasks for pulling out the old one, which is appropriate.

  2. Marcin Niebudek -

    I like the “dying feature” way of resolving such a rejection. This can in some circumstances lead to another smell. If we observe that every sprint some features die this way, then we should work with the PO in the earlier stage to improve gathering information for “ready to start” stories.


Leave a Reply