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.
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.
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.
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.
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.