How do you refactor a story?

Question

We've been using Pivotal Tracker on a software library project for well over a year. I'm the (admittedly not great) PM. The team is very good about writing notes on the story cards as things progress, but sometimes we start having whole discussions as story comments as new realizations occur concerning the topic of the story. I have a feeling that when too much discussion is taking place, it means the story needs to be refactored, but the following are not clear to me:

• What kind of criteria to use to decide when something should be done?
• What actions are possible: create one or more stories, and maybe (or maybe not) retitle the existing story as part of that? Are other options possible?
• Who should be doing that? The story owner?
• How do you handle reallocation of points? Do you add more points to the new stories? Do you adjust the points on the original story?

Basically, I'm looking for tips about how to detect when it's time to do something about a story, and what to do.

Answer 1

I'm not sure refactoring is the word you are looking for. Reading your description I would call it either "rewriting" or more likely "decompose" the story.

What kind of criteria to use to decide when something should be done?

If the team is confused, then something should be done.

What actions are possible: create one or more stories, and maybe (or maybe not) retitle the existing story as part of that? Are other options possible?

If a story is confusing, it is often to big. This is probably your number one issue. It is very common. See my suggestions below.

Who should be doing that? The story owner?

The product owner and the team. Ideally this work should be done during Sprint Planning.

How do you handle reallocation of points? Do you add more points to the new stories? Do you adjust the points on the original story?

I'm going to defer to better experts on scrum level implementation for this. My mentors have always cautioned against changing story points in the middle of a release. If you can break the story down into tasks, not full stories, then usually that is just the break down of the story and you don't story point the tasks (but many folks will man hour the tasks)

Here are four steps I have learned for breaking down vague stories into concise stories.

Find the Conjunctions: This is the first stage to user story break down. Take an existing story and find all the conjoining phrases (and, for, or, so, but, either, both, after, before, until, etc.). At each conjunction, break the story. Flesh out the one before the conjunction and move on. You can end up with several new stories from just a single user story.

Generic Words: “The user Logs In” can be a very generic statement. If your product supports multiple OS types and even mobile devices, then each one of those is its own user story. Anytime there is ambiguity in a word “Large,” “Easy,” or something you can’t test for, then narrow down the ambiguity. Often this will result in conjunctions (As a user I want to log in from my iPhone, iPad, Android, Mac and PC) and then you can break them down into their own stories.

Reverse the Acceptance Criteria: One of the advantages of applying acceptance criteria on even the vaguest user story is you then have a basis to dive into more information. Exploring having a masseuse for your day spa could quickly lead to both new users – As a private person I want the masseuse to come to my room, as an active person I want the day spa close to the beach and other water sports – and new stories – Mobile masseuses, Satellite location by the beach.

The truly helpful result is when the acceptance test gives you even more detailed user stories. The “Facial Treatment” acceptance criteria can lead to user stories to cover mineral treatments, mud masks, acupressure massage and so on. Each of these becomes the foundation of a new user story.

Time Line: The last in the line, this technique is particularly useful if you haven’t done Story Mapping on the product. Time line looks at a user story from the perspective of it being done and the team is asked to envision how it would work when done. This creates a timeline of events. Each event can then be turned into a user story.

Answer 2

It sounds like your team would benefit from discussing stories in more depth before starting them, and also breaking them down into smaller stories. If there's a lot of debate about what the story "means", then that is a good indication that the story was either too vague or too large. However, if the debate is about the proper technical implementation of a given story, then there may be nothing wrong.

That being said, here are my answers to your particular questions:

• If you are debating implementation details or tweaks to acceptance criteria, then keep the story as is and make those tweaks. But if the debate is larger than that, then a larger action is probably necessary.
• Assuming the story is too big, you should break it down into multiple stories that are more focused and have a smaller set of acceptance criteria on each story. You may want to group those stories together with a label or an epic.
• The product owner should be coordinating this process.
• It is perfectly fine to reestimate the number of points for the original story and the new stories.

All of these steps become harder and cause greater interruption to your development process if you do them once the story has already been started, so again, it's best to talk about the issues during your story planning meetings. However, agile is about adaptation, and so if a story has been started and still needs fixing, better to do it now rather than after the story has been "finished."