I have reflected a lot recently on how difficult it can be to deliver agilely estimated stories on time. Estimating is hard because you really can’t know how long something takes to do until you do it. But it is also easy after you starting a story to get off track into a cycle where a story is either underestimated or over delivered. So that looks like this.
Dev says I think this will take a day
Dev starts and works for a day, then keeps going
Dev delivers on day 2, story goes through QA and is finally delivered on day 3
Most of the time, the scope creep is discovered only after the story is completely finished as the manager is crunching velocity. The dev feels bad that he was 3 times slower than expected on the story and the manager wonders why their teams velocity is so low.
I think there can be a different perception on estimates. You can’t estimate the task, but you can estimate your perception of the task, and when your perception is off, it is a good opportunity to discuss the new perception with the other people on your team. In the scenario above, on day two the dev’s perception of the task was off and he needs to re-estimate the task with at least one other team member. This is a positive check and gives the opportunity to meet and ask the vital question “What are the alternatives to your current approach?”. At a minimum, your perception of the task has changed and you can discuss if your current approach is ok or if there are different ways to go at the problem.
Simple and effective. I think this could have several benefits with the main being the dev will focus on the problem instead of their current solution and evaluating the course they are going on relative to the overall big picture. It also has the positive check from someone else on the team to lend input. I’m not sure how this will pan out but plan on giving it a go and then will report back here after some time.