Oct 10, 2008

Handling Bad Task Estimations in a Sprint

Consider the following hypothetical situation I was talking about with Aaron a while back:

Fictional company ExWhyZed has 8 people in a Scrum team doing a 4 week sprint. The team is comprised of developers with some specific skills; basically 4 front end web developers who love their Silverlight UI's but suck at DDD and persistence, and 4 back end developers, who don't have much in the way of l33t web skillz.

Since they're doing Scrum they know they should deliver increments to the product in vertical slices, so they're all in the same team working on the same product backlog item, but coming at it from different ends of the equation.

During sprint planning the front end guys made estimates for tasks to delivering the UI, everyone worked together to estimate the front/back end interactions and the back end guys estimated their tasks for persistence and so forth.  The first few weeks of the sprint went OK but by week 3 the front end guys found that they've estimated some tasks poorly and are going to be late.  The back end developers also estimated poorly, but actually overestimated so they are all but done with their tasks by week 3.

If you were in the team what do you think you'd want the team to do? And why?

  • The back end guys should get more items from the product backlog and start working on them
  • The back end guys should just do more testing
  • The front end guys should give the back end guys some tasks to do
  • Front and back end guys should do pair programming
  • Back end guys should do some refactoring, catch up on blogs, do some reading, work on private projects, etc
  • The team should think about cancelling the sprint and start again
  • Something else?

And before you ask yes, this is genuinely hypothetical situation, but it is a fairly common one. I'm simply curious as to what you would do, and why.  Leave a comment with your thoughts.


  1. Front and back end guys should do pair programming

  2. I'm a Scrum Master (and developer), and have the same problem.

    In many contexts people can't (or won't) switch tasks with each other.

    Hence, not all can assign any task to themselves due to diverse competence profiles.

    The way I see it, and also address the problem, is that you have parallel sprints with the same start date and end date, hence more than one burndown chart.

    In my case that means one chart for the tester, one for the frontend developer, and one for the developers (five).

  3. +1 on the paired programming - or at least some closer working as in this situation there's effectively 2 teams and they need to work as one. This should be raised at the retrospective to find ways forward.

    For the sprint in progress, if not pushing for paired programming then I would be looking for the back end devs to get involved where ever they can to help the front end devs out. Maybe by getting involved with more testing or whatever it takes to help make the sprint a success.

  4. The reason this happens is generally because the back-end guys do a bad job with the UI and the UI guys have to compensate for them :-)

    There's no true answer, but by process of elimination:

    1) If they have tasks that they can work on that will add value to the current UI, then yes. But it's likely their new stuff needs new UI layers too, so in this case they should wait. But, they might use some of their free time to do some spikes on tricky things coming up soon.

    There might be things they can do on the back end to remove work for the front-end developers. Often things sound easier to do on the front end when they should be back-end, but those things add up.

    2) Maybe a little, but if they've already done their testing I wouldn't dedicate a lot more time.

    3) Possible, as the back end guys could perhaps look at making the bridge between them better (nicer API's, helping with proxy access and client-side domain models, etc.)

    Giving them UI-specific tasks, if they really have no interest, probably doesn't add much value (and probably adds more overhead, as someone has to teach them their way around the system).

    4) It depends how cohesive they are. A back end guy pairing with a front end guy while she codes front end code probably doesn't add much value, unless the back end guy is genuinely interested.

    They also might not have a lot of context around how the UI is put together. There's risk that their questions could slow down the UI guy. It might add value, but if the UI team is only a few days late, it's probably a net loss of productivity. Then again, it might be a good opportunity to use as a training exercise to get the back end guys across the UI design.

    That said, I might encourage the UI guys pair up between themselves.

    5) Not a fan of this. You might take the pressure off them to get things done, but since they overestimated there's a risk they'd continually overestimate on purpose to get free time (of course, it depends on the personalities - it might have been accidental or sheer luck). A full week of this kind of relaxing work generally isn't nice for anyone (or maybe I just speak for myself).

    6) You'd certainly re-evaluate the current sprint and cut work out that isn't essential, to stick to the original time box.

    I think you'd end up employing a mix of all of the above. Offload more work to the back-end, get the back-end guys to help with some of the front end, take the back-end guys who are interested and get them accross the UI layer, and reprioritise the work.

    Off topic, but what doesn't surprise me is that a team with no knowledge of DDD made a mess of things :-) DDD is about intelligently modelling and abstracting the problems you're trying to solve. UI's solve problems. So it's obvious that UI's should usually have a domain model and a client-side architecture, not just be codebehind to XAML files that call web services.

  5. I meant:

    The reason this happens is generally because the back-end guys do a bad job with the *API* and the UI guys have to compensate for them :-)

    But being serious, the nature of the one-directional relationship between client->server, not server->client, generally means the client guys are slowed down by bugs in the server, and not the other way around.

    I generally don't like horizontal partitioning of teams by technology, I'd much rather do it by feature groups and then specialities within groups. If you do that kind of partioning, I'd rather do shorter sprints as you'll want the integration/API changes/backlog evaluations to happen a lot more often.

  6. I would ask the team what they think they should do!


    Seriously it's a team effort and they need to work as a team to solve the problem. A solution that is not generated by the team will not be accepted as one that the team generates themselves.

  7. +1 to let the team decide, all the options are valid.
    If they're really commited to the project, they won't even consider the option of having free time.