PBI estimation: what am I missing or misunderstanding?
Hi all,
I'd like to discuss with the community about a topic that has been brought up by my team.
During the PBR (grooming) my team tends to go deep in technical details on how a PBI can be worked so that they can feel confident when they have to estimate it. They say that, if they don't know the how they will implement it, they are not able to do an estimation.
This cost us a lot of time and the PBR it's not very efficient.
I stressed the fact that an item (user story, for us) must describe the "What" and the "Why" it's needed (and we have to add details to that and to the acceptance criteria during PBR in order to estimate it when it is "ready") because the "How" will be defined during the second part of the Sprint Planning and that the estimation has to be performed on "what" and "why" (and A.C.)
I brought an example:
"As: Mark, car driver
I would like: to be able to slow down and stop my car
So that: I can approach the bends at the right speed and I can stop when necessary.
Acceptance criteria: I can slow down the car and stop it where I want when needed"
This describes the "What" and the "Why" (and the value in it) and how I can know if I've done it. The estimation should be done on this, the "how" will emerge during the Sprint planning for devising the work that will be necessary to do what's needed to complete the story (and here scope, readjusting the number of selected items for the Sprint and all the planning issues will be of primary importance).
I said to them that, regarding the story of the example, the hows can be:
1) Lauching a parachute
2) Using my feet (like the Flistones)
3) using brakes (disk brakes, electric brakes...)
and so on but this is still unknown during PBR, so it cannot be used for estimating.
The question that emerged is: "how can we make an estimation if we don't know how we will address the story?. Sticking to your example, launching a parachute is different (in term of complexity) than using your feet, so the estimation will be different"
While understanding what's written in the Scrum Guide and the reasons behind that, I have to say that the considerations brought up by my team have merit.
So, I would like to have opinions and suggestion from the community about this topic. Have someone else faced this kind of issue? Am I missing something or misunderstanding the Scrum Guide? How can I help my team to improve their processes about estimations?
Thank you in advance!
Regards,
Alessandro
This cost us a lot of time and the PBR it's not very efficient.
- How much time is it taking, as a proportion of the Sprint? Is it consuming more than 10%?
- How are you gauging the efficiency of refinement? Are the team finding, during a Sprint, that the estimates they made are unfit for purpose?
Hi Ian, all,
PBR activities are within 10% (usually 6/7 %) of the whole time of the team.
What I was trying to convey it was the fact that the team, without knowing "How" to implement a PBI, seems unable to estimate its complexity.
The effect is that there are long discussions about the "how to", which consume a lot of the available time for PBR and very few PBI are discussed during the sessions (this is what I intended -probably wrongly- for "inefficient" in my post).
The fact that sometimes, when the work emerge, the estimation reveals itself as unaccurate, it only reinforces my need to have clarification on this matter: while the PBI have to describe the "What" and "Why" and these have to be detailed/refined/estimated during PBR (the "How" being discussed at Sprint Planning time), the needs of the team for understanding (at some level) the "How" for making an estimation has merit.
So the question is: how can I help my team (and myself) understanding how to improve their estimation using only the "what" and "why" during PBR?
Thank you in advance.
Regards, Alessandro
So the question is: how can I help my team (and myself) understanding how to improve their estimation using only the "what" and "why" during PBR?
An estimation is and will forever be an estimation. It is no promise or commitment. You base your estimation on what is currently known and in a way your gut feeling. The Sprint Retrospective would of course be the perfet moment to identify how you can improve the way you estimate or when a PBI has enough details and information to take into the Sprint Planning. Maybe discuss when you as a team consider a PBI "Ready" and what you need more (or when detailing is too much). Hope this helps.
Thank you
We, ScrumMaster, Product Owner and Subject Matter Expert(s) make this more efficient by first meeting without the fulll development team to flesh out the What/What and then some of the How at a high level.
We then have a separate set of Ceremonies to discuss the How in detail with the developers (DeepDive).
As a ScrumMaster that we are looking for gotchas, anything that would catch us out when developer. List of the "how do we test?", "how to we demo", "how to we automate" the test. This should be enough for planning.
Estimates will never be 100%, only when the feature is complete will you truly know the estimate.
This is more. It must be done. Better to have this done before the sprint than during the sprint.
The question that emerged is: "how can we make an estimation if we don't know how we will address the story?. Sticking to your example, launching a parachute is different (in term of complexity) than using your feet, so the estimation will be different"
What all factors team considers while they make an estimation ?
We use an iterative approach: we do estimation as we do grooming. We have a roughly estimation for all non detailed tasks with low priority; when the priority changes, we take our time to analyze the PBI in order to make it ready and, in that moment, estimation could change.
I was a developer, let me say that understanding What, Exaclty What to do, for example using a QA test list, is enough to have a not perfect estimation, but something that in 90% of cases is more close to the real time that your team will spend in complete the task; because What, in a developer's mind, will automatically become How. Surely we could either over or under estimate something, but:
- this depends on how your developers know about the product and his implementation, and this surely will increase time by time, sprint by sprint
- estimation is estimation