Pages

February 8, 2011

Scrum Fundamental: User Stories

In my line of work as an agile coach I get to help people who are just starting to use Scrum. Some common problems crop up with many of these teams. If often comes down to some Scrum fundamentals. Fundamental doesn’t mean easy. Professional athletes work at the fundamentals and so must we.

If I had a short list of common problem areas, the neglected fundamentals might be: good stories, “keep it working”, getting to done, collaboration, and planning. That’s a bit much for one blog post, so, maybe over the next few days I can address these in a series of posts. Here’s the first.

User Stories


Analysis of a business problem yields features that may either be “stories” or that may be broken down into stories. The first pass will have stories that have some very important parts as well as some less important parts. Identify and implement the most important stories first and address risk first. Defer as much as possible to the end of the project.

That sounds obvious, but it’s so easy for a developer to “just add this in while we’re working in this area.” It’s seductive to the Product Owner to want to “round out” some feature set. So many useless features and dead code gets bought and paid for that way.

Maximize the amount of work not done. Be ruthless in deferring what is less essential until later; you might not ever have to do it. Don’t build frameworks in advance or build support in for features you plan to work on later because You Aren’t Going to Need It – the well known YAGNI principle.

Split Stories


The approach here is to split your stories. The “User Management” story becomes “Add Users”, “Delete Users”, and “Modify Users”. You might never implement Delete, and Modify isn’t needed in the first release. You may further split Add User into basic and wiz-bang versions. This can likely be split further to deal with different types of users, assorted permissions, error cases, cascading, and more complex attributes of the user. After splitting, implement the most valuable stories first, of course.

Each story should have some value to your business/client/customer, particularly to an end-user. Each story should deliver some function from top to bottom. It should be a complete vertical slice through your application. Don’t divide stories along architectural lines. Avoid technical/horizontal slices (the DB framework, the complete object model, all the UI components). For the “user management” story, don’t have a story for the UI and a story for the backend.

Spike Stories


Use spike stories when you need to figure out how to implement or estimate something. A spike is a short time-boxed experiment or research, with a specific objective to address unknowns and risks. The conclusion of a spike may beget more stories and spikes.

Rules of Thumb


Some rules of thumb for story size:
  • One story should not take the whole team more than half the iteration.
  • The team should be able to finish any story in one to two days for a one-week iteration.
  • The team should be able to finish any story in one to four days for a two-week iteration.
  • Aim to have 3 to 8 stories for a one-week iteration.
  • Aim to have 3 to 8 stories for a two-week iteration.
  • If most of your stories can be done by a person in half a day, they are too small.
  • If your team is doing more than 8 stories per iteration, your stories are too small.
  • If your team is doing more than 9 stories in a three-week iteration, your iterations are too big.

Remember, these are just my rules of thumb. There are valid exceptions.

Summary


Poor stories will make Scrum painful. I’m not the first to write about good user stories, not the most eloquent, and won’t be the last. If what I’ve written describes your problem, read more about it or find a good coach. I’m available.

Question for the day

Disagree with my recommendation? Have a better way to word this? Hate my rules of thumb? Have a better blog post on user stories? Post your thoughts or post a link.

No comments:

Post a Comment