Early subtasking at the beginning of each sprint

Question

I have joined a new team which is using Agile/Scrum, and their development process is as follows:

1) developers review each story before each sprint to make sure it doesn't miss anything critical. There's a formal state for that in the workflow.

2) during the Sprint kickoff, the entire team does an estimation (poker planning) on how many story points each story would cost.

3) finally, immediately after each sprint starts, each developer is required to eagerly break down all of assigned stories into subtasks with time estimates (as opposed to subtasking before starting each story).

The main argument for the last step is that it helps to discover if implementing a story would take longer than anticipated and warn scrum master about potential risks of missing sprint deadlines.

Yet I find this counter-productive, mainly because of the following reasons:

• if the aim is to provide rough estimate, story points (step #2) is what does the job. Otherwise why bother with story points at all? - just do subtasking early on.
• if the aim is to provide accurate estimates, then this is a clear example of what is described in Human Task Switches Considered Harmful. This, I think, is especially the case for fresh developers who join existing teams in big projects where understanding what needs to be done can take up to 50% of the time. You are required to get into details of story #1, then story #2, #3, etc. etc. which yields a lot of information churn.

I am also being told that such practice is "by the book" and I'm not even meant to discuss this. Can anyone provide a reference to such practice - whether this is clearly defined in Scrum bibles, and/or perhaps provide any extra insight?

Answer 1

This is not dissimilar to how we run some of our scrum process. We

1. Estimate stories near the top of the backlog in "story points"
2. Select/explain stories based on the story points that we think will "make up" the sprint
3. Break down the stories into more detailed technical tasks
4. Estimate the technical tasks and compare with the original story points estimate (we know approximately how much development time a story point normally equates to)

But what you want to know is why we estimate twice!

• We do a coarse estimate (based on the story) because we like to be able to make predictions about what might be in the next sprint, and maybe even the one after that. Ultimately management have to be able to communicate with the customer about likely time-scales, so if we don't have this coarse scale estimation then long term planning is virtually impossible.
• Obviously, this means we do coarse estimates for more than just the current sprint. Because there's no guarantee the backlog order won't change for the next sprint we don't want to invest the time in doing task breakdowns and fine-scale estimates until they're necessary.
• We break down the task to make sure that all the tasks have been enumerated and that stories can be worked on in parallel more easily.
• We do fine-scale estimates (based on the task) because this gives us a much smoother burn-down graph (particularly where there's no easy way to break a large story apart into viable "features").
• Because we do both, they act as sanity checks on one another - a wild discrepancy indicates we need a mistake somewhere that we need to identify. This is a useful by-product, but not the reason in itself why we estimate "twice".

Rereading your question and comment, I see there are some differences between our workflow and yours.

• We do breakdowns as a team, we find although the overhead is greater the technical discussion we get from this is often very valuable and can detect shortcomings in our story. When we have experience, knowledge or ability disparity this discussion is also where those with more can help out those with less (very useful with new hires).
• We do estimates at the task level as a team, one of the reasons why "planning poker" works is because of the "wisdom of crowds" phenomenon - as I mention in comments, by this point estimating a task should take less than 30 seconds, so the overhead is negligible.

It sounds like the reason your team does task breakdowns and task estimates is for a smooth burn-down - which is fine, that's all part of monitoring the progress of the sprint and allowing your scrum-master to detect and resolve issues early. If you want this information you have to do the breakdowns and estimates and you have to do them first.

In my opinion task switching is not likely to be a problem for you here, I don't think that breaking down different tasks is really a task switch in the same sense that flipping from developing one feature to another part way through is a task switch. I think gaining an understanding of the overall "architecture" of the sprint is probably quite a useful thing.

However, I think there may be some other problems you could consider. As always with agile you should identify a problem you have and propose a solution, then decide if your solution worked in the retrospective. This is the crux of building an agile solution that works for your company and your team. So, some problems you might have:

• You're doing breakdowns individually - so how are your junior/inexperienced team members learning from your senior team members? Sure, they can probably learn everything themselves - but they'll learn faster if they're mentored. Are junior team members taking a long time to break things down? Are they making mistakes or missing things that cost the team time in the long run? Breaking down as a team can help here.
• You're doing estimates individually - the same applies as the first point, but in addition are these estimates less accurate than they could be?
• It sounds like tasks are assigned at the start of the sprint, but if this is the case then how expensive are you finding it when you have to change the assignment? If someone is falling behind or ill, how easy is it for someone else to pick-up their tasks? Do they have to go through the task breakdowns and try to understand them without interrupting the original assignee? If you breakdown and estimate as a team then everyone should be able to work on everything!
• Are your stories too big? If the break down takes 50% of the time, the stories sound like they're very involved - perhaps they can be made smaller? We keep our stories within 1 man week of work.
• Are your tasks too small? If you're spending a long time making task lists maybe you're going into too much detail? We tend to have tasks between 1 and 8 man hours worth of work so that over the course of a day everyone makes some progress to report at the next daily standup.

Answer 2

If that's how your company wants to run their development and have shut down discussion, your choices are limited, or you at least run the risk of upsetting people.

Given that the ultimate goal of agile is working software of value, you could try offering to help out by measuirng your team's ability to deliver (points delivered/estimated, bugs in sprint, no. of tests, code coverage, uptime, sales generated - whatever). Be prepared for all outcomes - it may be that this way of working works for them even if it makes no sense to you. If you are right the waste will become self evident.

Be wary of following process for process sake - this wastes time and still delivers poor products. A good agile team experiments, measures and learns. The best way to change behaviour without descending into opinion is with evidence based decisions.

This is also my opinion. I suggest you try for yourself and measure the outcome - see what I did there :)

Answer 3

I would assume that your Sprint Kickoff means the Sprint Planning meeting. I think your Scrum Master misinterpreted how this meeting should go. You do not only decide on what stories to develop, you also test them to your team its definition of ready to make sure they don't miss anything (usually using INVEST), and you also subdivide those stories into tasks. To quote Mike Cohn (one of the founders of the Scrum Alliance);

The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated.

So the breaking down of stories and estimating them is all part of the Sprint Planning session; not after the planning session has finished and not individually.

To provide some more insight, our workflow during the Sprint Planning meeting is as follows:

1. we take a story from the top of the product backlog, and split it up into tasks. As a rule of thumb, one task should generally be smaller than a day.

2. We estimate the story given the tasks we've deducted. If the story turns out large, we try and split up the story into smaller stories.

3. Rinse and repeat until we reach the total of estimated points

Contrary to what Cohn says, I found that there is no real need to estimate each of the tasks separately, as the tasks are specified to be smaller than a day. Given that tasks are smaller than one day of work, you can easily notice during Daily Standup when a task is taking longer than expected, as the person working on the specific task will say that he is still working on it.

During sprint the team works its way through the stories, and at the end the team should reflect on how much actually got done. This is what the scrum retrospective meeting is for. If theres still stories on the table, you may deduct that your estimation was too optimistic and act on it for the next sprint. Alternatively there could have been certain incidents that occurred that affect how much you got done, etc. You will find that the estimations get better over time when you reflect on them.

Answer 4

"by the book" - that's your problem. You're drowning in more process than you would have had if you were working waterfalls.

There is no 'book' for Agile, there's only the agile manifesto that says "get stuff done without all the overhead". So, if you're estimating sizes and then splitting the stories up into tasks to re-estimate them, then that's a pointless process overhead that needs to be made more efficient - this is what agile is about. Scrum and all the others are really starting point guidelines for how you start doing agile. As you do it, you should identify these points that make no sense, or do not help your team work more effectively, and you should change them.

However, some people think that proscribed ways of working need to be written in stone and never deviated from, no matter how stupid they become. I would try to split stories into tasks before the scrum meeting - you say developers are required to review each story, well, here's the chance to do the splitting at the same time as part of the review. Then you can declare the tasks that comprise the story in the scrum meeting (do not allocate time to them!) and let people then decide how large a workpackage the story is, based on this additional information contained (which is never a bad thing, informed decision making is much better than guesswork,a nd can only be done when you have information to feed into the decision making).

After the meeting, you can still assign times to the tasks (though I fail to see the point of this, sprints are not based on time, they're based on "how much stuff you expect to do" which is measured in story points,not time. This is a common problem with scrum, points do not mean time but you have to complete, say, 20 points per fortnight therefore 2 points = 1 day's work. Its supposed to be a quick guess at how many tasks to put in the sprint so you are neither overloaded nor underworked, not how many will actually get done. The best sprints are those that have a couple of tasks left over, which shows you estimated perfectly. Completing every task shows people either rushed the last ones or delayed completing them at the end - neither is productive).

So, in short - print a copy of the Agile Manifesto out, and the anti-agile version. I bet you're doing more anti than agile. Scrum tends to be like that. The only way to fix it is to engage with your team and get buy-in for change. Don't let the management tell you how your team is to work, that's not agile either, and that will be written in The Book.

Answer 5

At some point during each Sprint, you should have a Product Backlog Refinement Meeting. At this meeting, you ensure that the top portion of the Product Backlog is broken down sufficiently for items in that portion to be added to the next Sprint Backlog.

If Product Backlog Refinement is managed well, then the Sprint Planning Meeting can be more efficient. Ideally, this would obviate the need for developers to "eagerly break down" stories after the Sprint starts.

If Product Backlog Items are added to the Sprint Backlog before being sufficiently broken down to estimate realistically, that will make it difficult to make good decisions about what to add to the Sprint.