An effective Agile shop starts with a well groomed backlog of user stories. This means collecting all of the user stories the organization is asking for into the backlog. But where to start?
Collecting anything is better than nothing but there are a few key data points that can really help when a user story has sat in the backlog for a while and gone stale. By capturing these anyone can come back to a user story later and pick up where they or someone else left off when it was captured.
Critical information to capture: Key Stakeholder, Statement of request in User Story Format, initial t-shirt size estimate.
Key Stakeholder
I've seen user stories that couldn't be linked to any stakeholder in the organization. So what happened to them? They stayed in the backlog, gathering dust, until the stakeholder raised questions about status or they died out. In the latter case there's not usually a major issue. The story just slowly fades away. In the former case though, the stakeholder is typically and rightfully upset that their request “fell through the cracks”.
The golden rule is that a user story never enters the backlog without a Key Stakeholder attached to it. At the very least this means that regular updates can be sent to the stakeholder letting them know that the item is still on the backlog but has not been prioritized into a sprint. They may not be completely happy about that but at least they know they haven't been forgotten about and that they are receiving consideration in relationship to other business priorities.
Request in User Story Format
This will save your bacon. Even if you have the Key Stakeholder identified it may not be enough if the User Story stated is vague or the goal of implementing it is unclear. When User Stories sit details get fuzzy in collective memory. Make sure you state a user story as, “As a <type of user> I want <specific feature> so that I can <realize specific benefit>.” This way, when you revisit the user story in the future everyone is on the same page.
This format also allows you to re-evaluate and determine if the story is still relevant. Ask the questions: Does that user classification still exist? Is that feature still lacking or has a subsequent effort already delivered it? Is the stated benefit still relevant and valuable to the organization? If not, you can quickly cull these user stories from the herd and move on to higher value targets.
T-Shirt Size Estimate
All user stories should enter the backlog with a high level t-shirt size estimate applied to them This is not a detailed estimate of hours to hold delivery accountable to. This is a first pass “Guesstimate” of what it will take, soup to nuts, to get the user story done. More of a classification than anything else.
The sizes I use are: x-small (less than eight hours), small (eight to forty hours), medium (forty to eighty hours), large (eighty to two hundred hours), x-large (two hundred to five hundred hours), xx-large (more than five hundred hours).
Sizes on the larger end of the scale are prime candidates for division into smaller user stories. I track t-shirt sizes with the Custom Fields Power Up in Trello and Tags in CA Agile Central (Rally).
Conclusion
There are more data points you will want to capture as you groom your user stories to get them ready for Sprint Planning but these three will insure you've got what you need to pick them back up once they've been ripening in the backlog for some time.
Question: What's the longest you've had an item in your backlog that you've had to come back to? How difficult was it to get it started? Leave your responses in the comments below. I want to get your perspective on how you capture work into your backlog.
