Backlog to Planning with minimal risk

Warning: a serious post, beware!

This time, I'd like to share with you the (what I find) effective technique of choosing sprint candidates, estimating as a team, and choosing the tasks to implement on a daily basis.

Intro:
The sprint planning main goal is to plan well the tasks we can do, not waste time on tasks we won't do, and understand their complexity as a team, right?

So let's split it up:
Before planning:
- Find the right sprint candidates
During planning:
- Estimate tasks until sprint planned capacity is reached.

Finding the right sprint candidates:
Before the sprint we try to sort the backlog so the quicker wins will be on top.

- Assuming the backlog is detailed enough to work with, the Product team attaches to each requirement a business value (1: lowest, and in the good old Fibonacci progression)
- The team's most senior developer assigns an out-of-the-cuff estimation (allowing a 400% margin of error, a really quick pass)
- we divide the Business-value by the Estimates, and receive a new ROI value.
- all items are sorted by it, and the PO picks the ones that he wants done, but takes into account (with a grain of salt...) the ROI value.

This way, we don't waste time estimating (let alone developing) things with lower value, unless PO insists (which probably means the Business value is higher that was noted...)

Estimates during Sprint-planning:
- Take the backlog items (chosen by the PM) one by one (sorted by initial ROI) and estimate them.
- When you finished the sprint's capacity, you are done.

However...
Time and time again we ran into a problem which we all know too well...
- Estimates are varying, and often the shy estimators lose
- Tasks sometimes take longer than expected.

Why?
So we though hard about it, and realize some tasks are riskier than others, causing both great amount of variance, and depassing initial estimates.

Solution:
Aha! - this is where we found the trick that shortens our estimates, and makes them more accurate than before...
During evaluation, a lot of time is spent because:
1. It is unclear how a requirement should be implemented.
2. Sometimes it is in the domain of expertise of one developer, and another doesn't know how to estimate.

So one estimates the task as a day's work, another as four days, there are some discussions, re evaluations, and sometimes someone just gives up to move on...

This is why we came up with the risk evaluation of a task:
- By default a task has no risk (hence we commit to its value)
- however, if estimate divergence is too high, or if all the team agrees there is a risk, we agree on the estimate, (a team member that doesn't know the code well enough can accept the expert's opinion...) but than ask everybody to define the risk (1: 25%, 2: 50%, etc.) and write down the highest one.

Now we commit only to the tasks with the risk included in the estimate, but try to implement at the initial estimate. hence the PO knows what is the minimum to expect, but also that we will probably produce more.

A few comments
- For each task, we record the two values - with and without risk, so the developer knows to aim at the no-risk planning, but feels safe to depass it for a risky task.
- Every task has the ROI recorded as well, so a developer would rather start during the sprint a higher ROI task, hence if not all task were finished for the sprint, still the effective ones were.
- And of course, the process is never automatic, ROI helps us choose, Risk helps us estimate better, but common sense always rules! (or at least should...).

Till nextime!