Rejecting User Stories
<Insert inspirational quote about rejection here.>
I’ve seen it happen too many times. An engineering team delivers a story. “As an existing user, I want to edit the fields on my profile page…”
The Product Manager takes a look at the newly implemented feature:
“Oh no! That’s not what I had in mind at all! A user should be able to edit most of the fields on their profile, but not their user ID!”
The Acceptance Criteria didn’t call out which fields a user should or should not be able to edit. What should the Product Manager do?
A) Open a bug
B) Create a new feature
C) Reject the story
The Product Manager hovers over the “Reject” button, but it just sounds so harsh. Let’s explore our other options.
A) Open a bug
“I guess I’ll just accept the feature and open a high-priority bug. We’ll make sure we don’t deploy the feature without the bug fix.”
This might not be a great idea. The “Bug” story type should be reserved for defects that occur after a story is Done. A story isn’t Done until the Product Manager’s expectations for that story are met. So, if there’s a “bug” associated with an in-flight story, it’s not really a bug yet.
B) Create a new feature
“I‘ll just go ahead and add another feature at the top of the backlog to fix it. This one will have all of the acceptance criteria I missed.”
All right, this is even worse than the bug idea. Adding a feature to “fix” another feature will artificially inflate your velocity, causing it to become volatile. If every 2-point story that doesn’t meet your expectations triggers a brand new 1-point story, you’ll need to start taking that into account when projecting potential release dates. I like math, but that calculation doesn’t sound fun.
C) Reject the story
Your best option is to reject the story, and it shouldn’t be a big deal.*
If you’re worried that the team will take the rejection personally, you could install a Chrome plugin that superficially renames the “Reject” button to “Revisit” in Pivotal Tracker. But, if you think a subtle wording change will resolve the tension, you might need to have a heart to heart with your team. On an agile and balanced team, the entire team shares responsibility for both the successes and failures, and a rejected story is no different.
*Actually, rejecting a story should be a big deal.
No individual is at fault when a story is rejected, but the team should understand what happened, why, and take action to prevent it from happening again. Every time a story is rejected, it should come up in your retrospective, or otherwise be discussed.
Perhaps the Product Manager tends to end lists with words like “and so on” or “etc.” instead of specifying exactly which items are affected. It’s possible that the engineering team made assumptions instead of asking the right questions. Or, maybe everyone interpreted an ambiguously-worded requirement differently. Communication breakdown, it’s always the same.
Don’t hesitate to reject a story when there’s still work left to be done, but make sure this happens as infrequently as possible.
