Agile – Early Subtasking at the Beginning of Each Sprint

agilescrum

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?

Best Answer

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.
Related Topic