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.