Use two-factor estimation when estimating tasks. #17
Conversation
jonathanknowles
changed the title
jonathanknowles
changed the title
jonathanknowles
force-pushed
the
update-estimation-process
branch
from
7f601d6 to
d5ec6ba
Compare
jonathanknowles
requested review from
Anviking,
HeinrichApfelmus,
paweljakubas,
piotr-iohk,
sevanspowell,
rvl,
SergiySa and
a team
| distribution model suggested above in order to capture the possible blowup | ||
| factor for the entire chain. | ||
|
|
||
| - [ ] When we have a release that contains large numbers of tasks with |
There was a problem hiding this comment.
After reading the linked article, this sounds like it might prove useful for informing better commitment dates around intense bodies of work (like the PAB integration). I think we experienced (still are experiencing) pretty significant blowup factor for that work, which wasn't well represented by our initial estimates.
| @@ -129,6 +186,38 @@ main task and linked. | |||
| We have found that Jira _subtasks_ aren't especially useful. They just | |||
| make things confusing, so avoid using them. | |||
|
|
|||
| # Other methods of estimation | |||
|
|
|||
| ## Story points estimates | |||
There was a problem hiding this comment.
I think this could do with some clarification: Are we continuing to use both story points and "most probable"/"most pessimistic" estimates?
There was a problem hiding this comment.
It seems like story points estimates are being relegated to the "Other methods" section.
This would be quite a deviation from our current process. Much more of a change than just adding an additional field for "est. time remaining."
We would need to seek guidance from the holy men of scrum about this.
In any case it would be nice to add more detail to the story points section - e.g. transfer the info from Sergiy's presentation slide, give examples of 1,3,5 point tasks, etc.
|
|
||
| ### Ticket must be ready to estimate before estimation | ||
| - These estimates refer to a number of days **remaining**, and as such they |
There was a problem hiding this comment.
Interesting, will this prove problematic to the current JIRA system? I think it presumes estimates are unchanged from the initial estimate in it's velocity calculations etc.
I don't really find those JIRA features useful anyway, so I don't really care, but might be worth running past Sergiy.
|
|
||
| ## Team Estimation | ||
| - Estimates should be created only after a _Task_ ticket has entered the |
There was a problem hiding this comment.
I like this a lot. We should only consider adding tasks to a sprint that are in a READY state. But is this process documented anywhere else? If so, could we add a link to it? I haven't heard about the READY state before.
There was a problem hiding this comment.
Yes, we should add a new page with our definition of ready, as it applies to estimation for task tickets.
|
|
||
| ## Interpreting estimates | ||
|
|
||
| Estimates do not represent commitments on behalf of those who create them. |
|
Thanks for putting the time into this Jonathan. I'm happy to give it a go! I'll leave off my approval until others have had a chance to say something though. |
There was a problem hiding this comment.
Thanks @jonathanknowles - it needs clarification about how these new estimates which are being asked of developers relate to the sprint points estimates.
| @@ -129,6 +186,38 @@ main task and linked. | |||
| We have found that Jira _subtasks_ aren't especially useful. They just | |||
| make things confusing, so avoid using them. | |||
|
|
|||
| # Other methods of estimation | |||
|
|
|||
| ## Story points estimates | |||
There was a problem hiding this comment.
It seems like story points estimates are being relegated to the "Other methods" section.
This would be quite a deviation from our current process. Much more of a change than just adding an additional field for "est. time remaining."
We would need to seek guidance from the holy men of scrum about this.
In any case it would be nice to add more detail to the story points section - e.g. transfer the info from Sergiy's presentation slide, give examples of 1,3,5 point tasks, etc.
| The decision on whether a task is included in the next sprint is | ||
| based on its points estimate and the project velocity. | ||
| - **Most-pessimistic estimate (days)**: the number of remaining days of effort | ||
| the task owner believes he or she will need to be 90% of confident of |
There was a problem hiding this comment.
I would prefer to stay well away from assigning numbers to confidence intervals. Terms like "quite" or "very" or "roughly" are far more appropriate I think.
Same goes with any pseudo-mathematical language, or using these numbers to calculate other estimates.
We simply do not have the historical data and estimation skill for that (... yet?).
There was a problem hiding this comment.
I initially had the same feeling that the "90%" number in the confidence interval would merely give an illusion of precision, but after chatting with Jonathan, I have also come to believe that a more qualitative formulation like "very confident" does not capture the intent either.
The idea is this: Even though we may not (yet or ever) have the historical data or skill to estimate that number, stating that we want to estimate the "90%" confidence interval is something that we could, at least in principle, compare to historical data. Put differently: Even though my gut feeling for the pessimistic estimate will always be the number of days that I feel "very confident" about, the more precise "90% confident" qualifier encourages me to anchor the specific number of days to a timeframe were indeed, 90% of the time, I will have been historically able to finish the task in fewer days. The purpose of the confidence statement is not to reflect my own confidence about the number that I estimated here, but to reflect the timeframe for which my estimate is supposed to be — even though my estimate for that may just be a wild guess for the time being.
I will try to change the text to make this more clear. I do feel that the phrase "I'm 90% confident" is semantically not well-defined (feeling about my confidence VS unit of measurement).
This PR updates our team estimation process to use "two-factor time estimation", instead of our current method of just using a single story point estimate.