Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

Sometimes teams get too enthusiastic, and while enthusiasm is a good thing, it can get out of hand. The temptation to add additional bells and whistles to a story in the sprint backlog can be a temptation that’s hard to resist, but resist we should. Why, you ask?I’ve seen my share of product owners, who are shown a feature, and respond “that’s most of what I want, but now that I see it, I want it to do X as well.”

So we respond to the product owner, “Great! Let’s create a new story and put it in the backlog.”  The product owner’s incredulous response is “But, that’s easy! Can’t we just add it to the definition of ‘done’ for the current story?”

And so we come to our dilemma: should we add a new story to the backlog for this feature, or should it have been part of this story from the outset? As good agile practitioners, we want to be welcoming of changing requirements, because we certainly don’t want to build a system that the product owner doesn’t want.

But at the same time, we want to keep the team from focusing on items that add little value to the solution we’re developing.  The mechanism we use to focus the team on the features that add the most value is a prioritized backlog.  If we simply expand our story to encompass the new functionality our product owner wants, then we short circuit this process: we never need to evaluate priorities.

It’s tempting for a product owner to avoid prioritizing stories in the product backlog. I can’t count the number of times I’ve been told “well, ALL our stories are priority one, we can’t live without any of them!”  It’s a silly argument, frankly, but if a product owner can get away with it, then they never have to make a hard decision, or satisfy one stakeholder at the expense of another.

Adding new bells and whistles to an existing story is just another version of avoiding prioritizing the backlog. If we can expand a story to include the new feature we just thought of, then we don’t have to prioritize it relative to all the other things we want.

So my inclination is towards creating new stories and adding them to the backlog. Certainly there’s a question of degree here: if the current story really doesn’t add any value without the new feature, then maybe it really is part of the story, but if the story is useful (just not as useful as it could be), then let’s make a new story.

I tempted to think this also makes our complexity points more accurate as well.  If the team estimates the complexity of a story based on one set of features, but the product owner adds a number of new features to the story as well, then the team’s estimate is out of whack, and that gives us an inaccurate team velocity.  I’ll be the first to admit, however, that this argument is pretty weak: team estimates are notoriously inaccurate to begin with.

The argument against expanding stories to add “easy” new features comes down to this: our team’s time is the most expensive resource we have, and we need to focus our team’s efforts on the features that add the most value to the business. The way we evaluate priorities and decide on what’s most important is by prioritizing the product backlog. If we don’t create new stories, then we rob ourselves of the ability to evaluate the benefit of the new feature relative to everything else we want from our new system. It’s not a good idea.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.