When to add tasks to stories and how to estimate tasks?

Question

In our agile team we frequently encounter the issue where the Scrum Master points out that all of our stories should be fully tasked and estimated prior to an iteration and once these tasks have been added no more tasks/stories can be added during the iteration. In my opinion this is very difficult to accomplish unless the item of work is fully understood. In my experience trying to fully task a story prior to actually working on it is difficult because :

1. I don't know what the tasks will actually involve until I familiarize myself with the code in that particular area.

2. Even when I familiarize myself I will be constantly reading doc's etc to improve my understanding and look for efficiency's thereby possibly making my original tasks redundant.

Perhaps this is not very agile of me but it feels like the best method of adding value to the work being done. Am I just being too rigid or is there a common approach to solve this issue? Is this issue common among users of this site as it seems quite common to developers I've worked with?

Answer 1

Plan well. But be prepared to change, if you run into roadblocks.

When to add tasks to stories and how to estimate tasks?

You should add tasks at the time of the Iteration Planning. The dev team should have a game plan about how to accomplish the story. In my experience estimating the tasks in hours is found to be helpful. However, it should be clearly understood that the hours are only for the purpose of internal team coordination and not for management to use as baseline for performance measurement.

our Scrum Master points out that all of our stories should be fully tasked out and estimated prior to an iteration.

I agree with your Scrum Master this should be done prior to the start of the iteration. This is the primary goal of the Iteration Planning meeting.

no more stories can be added during the iteration.

I agree with your Scrum Master on this. This is the basic premise of Scrum.

no more tasks can be added during the iteration.

I don't agree with your Scrum Master on the no more tasks part. This is the waterfall (predictive planning) mindset. Scrum's (adaptive planning) premise is that software development is partly R&D type of work. You should start out with a specific approach to do the story based on your best judgment. However, if you run into problems a task may take longer than originally estimated. In some cases, your initial approach may not work at all and you may have to try another approach. At this point, you can re-estimate or redo the tasks.

Where there is high level of uncertainty, I ask my teams to do a time-boxed research story (spike) in the previous iteration. This might involve doing a proof-of-concept to validate an approach. Then the commitment of the team to accomplish what they signed up to do is much more firm.

Even when I familiarize myself I will be constantly reading doc's etc to improve my understanding and look for efficiency's thereby possibly making my original tasks redundant.

This sounds too tentative. You should understand the requirements well and have an approach planned at the time of making a team commitment in the Iteration Planning meeting.

Answer 2

The most common reasons people struggle to estimate that I've seen are:

You're trying to be too precise

It can help to have some stories you've done previously available when you estimate to use as benchmarks.

If you've got an example of a 2, a 5, an 8 and a 13 point story, bring them to your estimation session. Hopefully it'll be easier to estimate along the lines of "it's definitely bigger than the 2 point story and smaller than the 13 point one." in which case it's either a 5 or an 8, pick what you feel is closest.

Remember, the purpose of estimation isn't precision. You'll go too big sometimes and too small on other occasions, it all evens out over time.

Insufficient acceptance criteria

If the acceptance criteria don't contain vital information, estimation is tough. Things to watch out for are phrases like "replicate current behaviour". If you don't know what the current behaviour is, it's going to be really tricky to get an idea what the size of the story will be!

Get your product owner/business analyst to clarify before you accept the story!

Your stories are too big

To use the example Daniel gives in his answer:

As a user, I want my final bill to account for any discounts available to me.

Try breaking the story up into smaller chunks. Perhaps:

As an early subscriber, I want my final bill to account for my early bird discount.

As an employee user, I want my final bill to account for my staff discount.

As a loyalty card holder, I want my final bill to account for my loyalty card discount.

etc.....

Smaller stories are generally easier to get a feel for and less likely to involve multiple systems etc.

There are big unknowns

Perhaps you've not worked on this code before. Maybe you're building something that's dissimilar to anything you've got experience of. Could be that you're using a new 3rd party tool and you have no idea how it works. This kind of stuff makes estimation pretty much impossible as you have very little to base an number on.

In this scenario, it's a good idea to do a spike to help you understand the issue at hand.

Answer 3

I've always taken it from this point of view:

If you can't task out the story because you don't know what tasks need to be done, how do you know how large the story is to estimate it and how can you commit to having it done?

In these situations (and they are very common) it usually means that a story is either too broad (it's not that you don't know all the steps, they are just too many to practically enumerate) or too vague.

For an example, let's say I have this story:

As a user, I want my final bill to account for any discounts available to me.

That could be a single field or it could be spread out in 10 different systems, 2 of which are in excel. I've run into a lot of friction at this point because of people's ideas of what a deliverable story is. I would tell you that you should have a research story with a concrete deliverable like:

As an account exec, I would like to identify all possible sources of discounts.

I've had people balk at that because it's not a feature delivery per se. Those people would say that is the business's job to determine and provide, but a lot of times these end of being very technical questions because the account exec might see it all in one or two places, but it's really in a number of databases. I personally think it's worth fudging agile a bit to get the job done right, but maybe others can offer an alternative.

The other really big problem with this is that, if you take that story on and you fill the rest of the available effort in the sprint with other stories, actually implementing code based on your findings will have to wait until next sprint. There's a pretty simply solution to this. Leave room in your sprint for more stories. If your velocity is 60 points, only commit to 45. That can give you the room to create and pull in more stories to implement your solution. Again, we're on grey area of Agile here, but I think it's getting the job done and keeping with the intent behind those Agile rules.

Hope this helps!