Improve Your Story Breakdown
The most effective technique that is often overlooked.
--
One of the fundamental abilities required by Agile software development is the capacity to properly breakdown stories. This plays a crucial role in the capacity of performing short and quick iterations, while it helps business to efficiently deliver software solutions. Yet, this is not an easy task. Often user stories are too big, and teams have to split them to track advances properly. But this is far from the best option that we have. In this article, I will explain why, and present an alternative about how to properly breakdown stories.
Why breakdown stories
The most well-known reason to breakdown stories is to increment the predictability of teams, and to be able to track their advances.
When developers breakdown stories into smaller chunks, they are more aware of all the steps required for their implementation, and they provide better estimates. That increases their predictability. On the other hand, we also want to monitor the advance of the team. The most popular way to track the advances is through a burndown charts: it shows the total remaining effort by day. These charts allow us to track how developers are completing their tasks daily. If stories are small enough, we can see how the total of tasks to complete decreases every day. But, if tasks are too large, instead of visualizing a reduction of pending tasks daily, it might create gaps of days, or even weeks. And we are not able to track if their progress is the expected, or if developers had problems.
In short, according to these two reasons, we can get predictions about when features will be completed, and also track how wrong predictions are. Because, you know, it is always good to know how wrong we are.
Yet, there is a better reason: being Agile.
Think about the tracking completion of stories. What is the purpose of being able to track it? If we plan iteration by iteration, the most useful purpose of detecting delays in story completions, is being able to help the developer to overcome…
