What are the disadvantages of performing task breakdown before story estimation?

Question

I have trouble with some of this jargon so I apologize if I misuse some of it.

In my past experiences Story Estimation (planning poker estimating how difficult/complex certain tasks will be with fibonacci numbers) happens before Task Breakdown (figuring out the implementation details of how the team thinks we should implement the storys that have been estimated and slotted for an incoming sprint).

I feel that doing Task Breakdown before Story Estimation,would be advantageous for junior or new team members especially if the codebase is large or complicated.

But I feel story estimation would be easier and more accurate if Task Breakdown occurred prior such that the team has discussed how the would like to implement something, and thus understand how "hard" it is. But I have never seen this.

What are the disadvantages of doing Task Breakdown before Story Estimation?

• Story Estimation could be "tainted" as the the task has been broken down?

• Planning could become trickier as you will need to breakdown many more stories to have them ready for estimation to be considered for an incoming sprint

• Participants can influence each other's opinions on how difficult a task is (for story estimation if it occurs after task breakdown) during task breakdown

Answer 1

bear in mind that story estimation is exactly what it is, just an estimate therefore it doesn't have to be 100% accurate. Defining all tasks for all stories before estimating would take forever. Ideally, the details of each story is only fleshed out during sprint planning. However, all stories in the backlog have to be estimated even before they are selected for sprint planning.

One reason why this is the case is for scope definition and resource planning. I'm a Business Systems Analyst and sometimes work as a Technical Product Owner. Anytime I join a new project, within the first 2-3 weeks, the project sponsors want to know the scope of the project, which means I need to come up with a way to determine the amount of work to be done and how long it would take.

As usual, I would facilitate story writing sessions with the stakeholders (Business Product Owners), then with a handful of the dev team estimate the user stories. After that, we would run 2-3 sprints and from that determine our average velocity.

Therefore, to determine the duration of the project, I need 2 parameters....1 is the scope i.e. the number of user stories (all estimated) and 2 is the average velocity

I then use the formula:

Total number of sprints = total story points divided by the average velocity

If my total estimated story points = 700 and our average velocity = 70

Total number of sprints = 700/70

Total number of sprints therefore = 10 sprints

I then convert sprints into months and weeks. Therefore, if 1 sprint equals 2 weeks, 10 sprints would equal 20 weeks (5 months).

This figure is of-course not set in stone and is reviewed regularly once we start adding new stories to the backlog but this gives the business a rough idea of how long the project would take, how many resources to recruit, and how much the resources would cost for a period of 5 months.

The reason why I have broken it down this way is because we wouldn't have been able to provide the business with this critical information if we had to wait for all the details of the user stories to be fleshed out before estimating them. I hope this explanation helps.

Answer 2

I would say that sequencing the breakdown before estimation defeats the main advantages of doing both estimation and breakdown.

Estimation is a coarse assessment of complexity that helps you decide a) whether a story is clear enough to be ready for development and b) which stories can be included in the sprint scope given past evidence of the team's sprint capacity. Whereas task breakdown can sometimes involve long discussions and technical details, estimation is "cheap and cheerful" and immediately reveals incongruence between developers' impressions of the story's complexity.

If you do the breakdown first, you'll use up valuable time on stories that may not even make it into the sprint, and which may change before they're included in a subsequent sprint. In addition, doing the breakdown first means you don't have an estimation against which you can compare your breakdown. If the breakdown reveals noticeably different complexity than the estimation, there's an opportunity to learn something useful about your story, product, or team.

Task breakdown provides the level of granularity needed to actually begin working on a story. It aids with division of labour; it clarifies the technical "definition of done" for that story; and may bring to light disagreements about design and architecture -- which can be discussed amongst the team so expertise can be shared. At this point, estimation of the story seems rather redundant since you could more accurately estimate each part of the breakdown anyway.

It's important to think about the reason we a) estimate stories and b) use Fibonacci numbers. The rate of growth of Fibonacci numbers is a useful approximation for the relative growth of uncertainty with complexity in a nonlinear system (such as software development). As complexity grows, so does the margin for error in predicting the system. A task breakdown is almost irrelevant to this level of granularity. For new developers who don't necessarily have a sense of what a story entails, a quick explanation about high level architectural and design considerations would be faster and potentially more helpful to the estimation.

If you really think the task breakdown details are important to your estimation, it could mean that your stories are too complex to estimate with any useful precision and that there's a lot of room to improve your agile process.

Answer 3

Story estimation is a way to have team consensus how difficult and extensive a story will be, and that all of you have the same detail understanding. Fibonacci numbers are abstract numbers and does not express days or hours you will spend working on a story.

In agile we don't care how long exactly one single story will take (it was typical thing in traditional software development). We know that it has to be done in 2, max 3 days and it is enough. Remember that a story is not done until it is developed AND tested.