Better eatimations
Hello Everyone,
I want to ask a question that I believe all of the Scrum Masters have ran through. There are times when the estimates are completely off. I am currently working in a team who is focused on an employee enrollment project.
When they are in the backlog refinement with the user stories, it seems to be fairly simple for them. They voice that the effort is not too complex. They initially point it at 2 or 3 points. However when the team started working on the user story, they realize that the configurations in the back end are extremely complex. In reality, the story points should have been a 8 pointer.
Having talked with the team, they voice that they would not be able to estimate properly until they have their hands dirty in the code. Do you all have any ideas on how to approach better estimating? What can we do if the developers can't estimate without getting their hands dirty in the code first?
They could experiment a bit with a spike investigation in Product Backlog refinement. Another option is to simply observe the rate of throughput, and use that to forecast empirically how much work can be taken on each Sprint.
The important thing of course is not to estimate work, but to be able to frame and meet a Sprint Goal commitment. Are they planning enough contingency into their Sprint Backlog to allow for the complexities they are discovering?
The problem doesn't appear to be about estimation, but about understanding the necessary work to achieve the task. The question I'd be asking is why the Developers don't realize the complexity of the configurations until after they start work. Alternatively, why do they need to "have their hands dirty in the code" to realize this complexity? Once you understand the answers to these questions, the team will be able to improve their refinement of the work. In some cases, they may also be able to better split Product Backlog Items into smaller pieces. Improved estimation would be a side effect and not the goal.
I agree with @Ian and @Thomas. This isn't necessarily a problem with their estimates. Remember that estimates are guesses made based upon the information you have at the time you make the estimate. Once work begins, the original estimates are basically useless.
What I see as an issue is that your Developers do not fully understand the complexity of their environments if they continuously discover that the backend configurations are complex. If I were involved with this team, I would bring it up in a Sprint Retrospective where the situation arose. The Developers can say that they won't know until they "have their hands dirty in the code" which may be true. But based on history, they should be able to start making better assumptions on how complex the work could be and factor that into their original estimates.
Having talked with the team, they voice that they would not be able to estimate properly until they have their hands dirty in the code. Do you all have any ideas on how to approach better estimating? What can we do if the developers can't estimate without getting their hands dirty in the code first?
From technical point of view,
it is better to provide walkthrough in the system and point it out the requirement like adding button, change process, etc.. usually the developer will be able to provide closer estimation
From relation point of view
it is also possible the developer do not understand the explanation... sharing the requirement earlier will help or if time permitted usually I will discuss with him / her directly (the point of scrum is collaboration over documentation / reporting)
if this doesn't work, pairing him / her with other colleague with better communication skill will help also
The easiest answer, of course, is to stop estimating.
However, If they can't estimate properly, they may not be refining as good as they could? Is the refinement enough for them to know what they need to do?
If refinement is enough, the answer is to look at Cycle Time and Throughput, and to just say: "we can do X PBIs in a Sprint" and keep it at that. At least, I'm guessing the Sprint Backlog is way too long?