Writing Better User Stories - Part 3 (The right amount of detail)

Ideally a user story should be more than a quarter of a sprints velocity. If this is the case then user stories should be able to be finished during a sprint in most cases. If the team is having trouble completing user stories it may be that they have too much or too little detail. Below are some techniques for determining what the right level of detail is for a story.

Too Little Detail

If a story does not have enough detail you may find that there are too many unknowns and result in there being a lot of questions to product owner during the sprint. The delay here is during the sprint and development and is very visible. The answers can delay the development or increase the complexity of the story as well.

Too Much Detail

If a story has too much detail you may find that the team has tried to remove all uncertainty from the user story and that new functionality is taking longer to deliver from the point the request for new functionality was made. The delay in deliver here is hidden by spending lots of time refining the story BEFORE it is brought into the sprint. This shows in areas like acceptance criteria with too much detail, or all screen designed completed, or not allowing a story into a sprint if it has an uncertainty. If all creativity has been removed from the developer there is probably too much detail.

The Sweet Spot

Ask the team "Did you get just enough detail to complete this iteration's user stories and was that information provided just in time?" in the retrospective. This will help in future stories. Strive to get the right level of detail "on average", not every story.

Detail should be provided "Just enough and Just in time" because too early and the information will be out of date by the time the team works on the user story. The will likely cause delays in the sprint or waste time reworking a story.

Analysts job with Agile is to provide the information Just in Time since there is not large chunk of analysis done at the start of the project. This is in contrast to traditional waterfall methods where there is an initial stage where the analyst figures out all the details upfront. This means that the chances that the analyst will get the level of details or get something wrong increases. This means some (a small number) stories will be affected, but not likely all of them. However, this is better than building in delays, padding, etc into every story.

The idea is striving for perfection when moving this fast will not be effective. Consider something like Fedex that has 2 day delivery. They expect that a low percentage of packages will not be delivered as expected. The alternative is to not have 2 day delivery and guarantee 5 day delivery instead, or increase the number of staff, planes, vehicles, etc. These would affect the price of the product as well as reduce the overall benefit that most people experience just so we get 100%. The same can be said for Agile projects.