What do we do when work is underestimated?
An executive in our company recently asked for a report that would show when any individual developer went a certain percent over an original estimate. This was my reply... What are your thoughts?
Executive:
The use case is Developer X put in an estimate of Y, but now is at 4Y, or 4 times over. We just want a good way to catch those kind of incidents before they get out of control.
Answer:
Thanks for the use case. It helps to know what problem we are trying to solve. I think the Scrum answer is that those incidents get caught by the Scrum team during daily Scrum when Developer X reports on what he did (or did not do) since yesterday, what he is doing (or still doing) today, and whether he has any blockers. If he is going over on his original estimate, the team should notice that when he reports that he is still working on something that he said he had started yesterday because all tasks should be under six hours. If he has impediments that are causing that delay, he will mention those during his stand-up, and the Scrum Master can then work to help remove those impediments. Now we have the problem caught and addressed before it gets out of control.
Basically, we rely on transparency, inspection, and adaptation to help us course correct during a daily inspect-and-adapt opportunity.
If Developer X is taking longer than originally estimated for some reason other than an impediment, e.g., underestimation of the original work, then the issue gets called out by the rest of the scrum team if and when Developer X has tasks that are not done by the end of the sprint. In which case, the team reviews root cause during the sprint retrospective. If the self-managing team determines that the root cause is estimation and not some other type of impediment, then the team should ask the following:
1. Were the requirements and acceptance criteria fully defined and understood during sprint planning?
2. Did Developer X and the team sufficiently break down the user story into tasks as much a possible during sprint planning?
3. Did Developer X make an original estimate in hours for all child tasks as accurately as possible during sprint planning?
4. Did any original tasks exceed 6 hours of time?
5. Did the requirements evolve or change as work progressed?
6. Did resources constraints or competing priorities affect progress on work?
7. Did the team hold daily Scrum?
8. Did all team members report not only on what the are doing today, but also on what they did since yesterday, and on any impediments?
From what I've seen so far, this use case happens when Developer X does not take the time to fully break down work into all required tasks, or when the tasks are not granular enough (6 hours or less). It also happens when the sprint backlog evolves fully and requirements become better understood, which we expect and which Scrum allows and accommodates. I don't think we need a report by team member in either case. I think it is a training issue, and we work to help the team stay within the rules of the Scrum framework. We track this particular issue at the team level with our canned report, and follow up with teams that are underestimating or not meeting the definition of done within the sprint as a group.
Thoughts?
Wow! that is excellent answer, Joshua.
I total agree with you about your way to detect root causes and how to solve it in next sprints.
Transparency, inspection, and adaptation is the key words for this case. The causes can be occur during all sprint as you said.
- Sprint planning not well: analysis requirement not really clear, break task not enough small
- Daily meeting: not answer all 3 questions then have actions for issues or impediments. Developer X should report how much time he need to finish his task also instead of only tell to team how much time he spent.
- Sprint retrospective: That really important to get lesson learns for next sprints.
Just to remind for Executive, "The use case is Developer X put in an estimate of Y" it's strange. In Scrum estimation should be done by whole Development Team, not by an individual. Do you agree? :)
Regards,
Ba
Thank you, Ba. I really appreciate your note that developers should also report on how much time they have remaining on tasks. Very good point.
Concerning collaborative estimation, I do agree that PBIs should be estimated by the whole team and never by an individual. We unearth a lot of "gotchas" and find "shortcuts" by crowdsourcing estimation to the collective. In this case, our exec was referring to child tasks of PBIs. I wonder how others feel having the entire team estimate tasks in hours.
I suppose it may come down to the scale of operations. We are a larger organization and are using the Scaled Agile Framework. We have our teams collaboratively estimate product backlog items in story points during planning poker, but the child tasks are assigned to individual developers who give their own estimate in hours, usually without input from the team. I don't know that we have ever considered having the team estimate tasks together, but I can see how that might have the same benefits as collaboratively estimating our user stories.
Best,
Josh
oh yes, you are right. It is not necessary to involve whole development team for estimation child tasks of PBIs, especially with experienced team.
I think with lower level of self management team, new with Scrum you can apply planning poker for child tasks in hours for some first sprints. By this way, newbie can learn a lot from experienced member how to estimate more exactly. You know, to estimate product backlog items in story points we have 2 typical ways:
1. Everyone need to imagine all child tasks relate to PBI--> Estimate them--> Summary to story point.
2. Base on some historical PBIs which Scrum team already finished in previous sprints, compare with current PBI-->get related story point
So in first sprints we have no historical data of estimation, obviously you should use first way, I think.
If your executive spent as much time ensuring the value of the work as he/she does micromanaging estimates, I'd buy stock.
Ken
Well said... and too painfully true! ;)
Ken, perhaps you and others here could share your insight/advice on what you have seen work in getting that "Don't lose the end in the means" message across to the C-Suite and above.
My approach to requests for micromanagement facilitation has been three-fold:
1. Find out what problem the exec is trying to solve by micromanaging
2. Explain how Scrum solves the same problem with self-organizing teams
3. Ask if the Scrum way is an acceptable alternative means to the end
Crucial conversations follow… ;) That has often worked, but admittedly, only after repeated and consistent redirection.
Our execs definitely care very much about value, which usually drives their micromanagement. Most have made the Agile transformation, but old habits die hard – harder for some than for others. Not all have caught the vision of focusing their attention on maximizing flow of value while letting the team worry about the means.
What should they do to ensure value? (guiding strategy, empowering the product owner, facilitating for the team, giving feedback in reviews, etc…?) And... how do we communicate the proper vision and frame that message for the C-level?
Mahalo!
Josh
> Our execs definitely care very much about value,
> which usually drives their micromanagement.
Value is determined by testing assumptions about market needs. Typically the business arm of an organization is best positioned to do this and not a layer of executives. Business can identify the minimum viable product needed to confirm or refute value assumptions, and agile development teams can help them deliver increments of the relevant product or service.
The message should therefore be that if executives care about value, they must help to facilitate this mechanism. In Scrum terms that means empowering the 3 Scrum roles...including Product Owners who account for value...and then optimizing these arrangements for success at enterprise scale.