Sunday, September 9, 2012

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.

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.

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.

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

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!

Wednesday, August 8, 2012

Bad hair day

I think it was the Dalai Lama who said - if you lose, don't lose the lesson,

My last post (real life, not blogging) was an effort to manage a project the scrum way, and I admit (to myself, at least) I failed miserably...

So, in tribute to the Dalai, what lessons did I learn about Scrum implementation?

Or: subtitled, warning signs in scrum implementation.
Before starting, two comments:
  1. This post's sole purpose (except entertain ya) is to serve as a postmortem checklist for the health of your process.
  2. A small disclaimer, as all of my posts, this is just about me, highly subjective, take it all with at least one grain of salt,
Or in other words:

And now for the list, bottm-up:

Development team side:

  1. A team member refers to the sprint as your sprint (example phrase: "this is the last time I stay late for your sprint").
  2. A team member states he knows what scrum is, and that you don't (example phrase: "this is not how scrum is done, in my previous company we did scrum and there was a full spec for the whole version before we started the first sprint").
  3. A developer does stuff that is not required for the sprint, but that he believes is required in the 'final' version, and than complains he didn't get enough time to deliver his task. (example phrase: "no need for a code review, I know my code sucks, but I had to implement two servers that communicate between them, since otherwise the solution is not scalable and the final product will not support high load, and that's why the two day task is not finished though I am working on it 6 days already", sometimes followed by "I need just one more day")
  4. Team bonding: when the only glue the team has is the the consensus about failure/ how the product sucks/ how the QA or Product manager or whoever doesn't know his job.

Product management:

  1. No vision: the question where do you want the product to be in 1 year? two? five? meets a blank stare.
  2. Constant panic: new urgent customer needs bypass the sprint, one product is stopped mid way to start a second one, which is stopped midway to start a third one.
  3. 'User story', sounds like a strange concept, and the delivered spec has redundancy, contradictions, and outdated sections.
  4. Everything is top priority.
  5. PM located on a different floor than dev (higher).
  6. There are several PMs, each with his own priorities.


  1. No space is dedicated for the team (no wall can be dedicated for the daily standup, no whiteboards in any meeting room since all walls are made entirely of glass (on which you are not allowed to write on with a marker), except for one with a plasma TV.
  2. Your manager (the one that hired you to propagate scrum to the system) calls all the project managers one day to a meeting where he announces that today is his last day on the job, and wishes you all luck..
  3. Management doesn't know team members by name, and presents yearly plans without consulting the team.

(last but not least...) You:

  1. The days you come to work optimistic/ happy/ motivated get rarer and rarer.
  2. You start a blog-post with everybody else's symptoms and put yours in last place.
  3. You stop doing Scrum, (and no one asks you why)
  4. You stop publishing the Blog you started on scrum, since you have no positive experience to share.
  5. You start looking for another workplace.
Here's lookin' at ya, Lama!

- Till nextime!