We just finished the series of planning sessions for Sprint2 which began on Feb 19th and runs for 4 weeks. We prioritized, decomposed, and estimated the work to be done and estimated how much could be accomplished in the 4 week period.
Planning
The planning sessions which include the scrum masters, product owners, and developers started after each of the product owners had their respective product backlogs prioritized. The team spent hours together decomposing the items on the product backlog into bite-sized, testable pieces that could be estimated. It was a challenging learning experience for everyone, mostly around effectively time-boxing discussions and knowing what to discuss and what can wait, however we came out of it relatively unscathed, and definitely wiser and more cohesive for the experience.
Estimating
After we had enough tasks broken down we gather the team of developers together to estimate each of the tasks. The purpose of this is to know how much the development team can be expected to produce in a sprint. The development team must be comfortable with the commitment and the product owners must be confident that the team will deliver on that commitment. We always plan more tasks than we think we can develop in one sprint so we don’t exhaust the available pool of work if the team performs better than anticipated.
The estimates are given in jellybeans rather than days or hours to avoid the myth that we can give such precise predictions about the work to be done. This is a myth that has been hurting development teams for far too long. Some things can be predicted very accurately such as, “How long does a direct flight from Saskatoon to San Francisco on a 737 take ( if such a flight existed)?” Others like, “How long with this football game take?”, can’t be predicted as easily. But it can be estimated.
What the heck is a jellybean?
A jellybean is an abstract measure of the size of a development task. To give the football analogy, we might consider that 1 quarter of a football game takes 1 jellybean. That means a whole football game takes 4 jellybeans. Although we don’t know exactly how long this is, it’s usefull nonetheless. For example we may want to know how long it will take to play a football game that consists of 10 quarters. That’s easy: 10 jellybeans.
Velocity is important when considering how much time it will take a team to produce one jellybean worth of work.
Velocity
Velocity is the measurement of how many jellybeans a team can accomplish in one sprint. It’s not something we can determine ahead of time with any confidence or accuracy, but rather something that is measured over time. I’m sure you have experienced being on a development project where you we’re given a task AND told how long it must take.
“Please have this TPS report generator completed by Friday.”
In football, the health of the team, injuries, penalties, weather, commercials, etc. all contribute to the velocity of the game. It may take 1 hour to accomplish 1 jellybean (1 quarter or 15 perfect minutes) of football. This is something we all understand and accept.
With a measured (and therefore predictable) velocity of 100 jellybeans, we would know that the team of developers has demonstrated over an extended period of time that it can accomplish 100 jellybeans worth of work in one 4 week sprint. Changes to the team size, nature of work, distractions in the office, advances in technology, professional development, etc. will all have an effect on this velocity.
Ideal Developer Days
There are several techniques available for estimating the size of each task, the least abstract being ideal developer days which is exactly how we did our estimation.
The team is asked to arrive at an agreement about the number of ideal developer daysa task will take by getting together in a room and playing estimation poker. Each team member comes up with an independent estimate. We all share our estimate with the team (on a card) at the same time, then we discuss discrepancies in estimates until the majority agree. At first it was uncomfortable for me, and I sensed for some other people as well, to look around at the number of people in the “meeting” and think about how much time we were wasting. However it became obvious that the benefits were outweighing the cost. The team left these estimating sessions with a shared commitment to these estimates and a better shared understanding of what work needed to be done.
Relative Task Size
An alternative to the ideal developer days technique is relative task size. This technique still uses estimation poker, but instead the team is asked to arrive at an agreement about the size of a new task relative to the size of some tasks that have already been accomplished.
Let’s return to the football analogy. Suppose the team is asked to estimate how big a period of NHL hockey is. Well they know that 1 quarter of football has been estimated at 1 jellybean and they have the option of estimating 1, 2, 3, 5, 8, 13 (you may have noticed that these are numbers in the Fibonacci sequence) There might be a debate about whether a quarter of hockey is 1 or 2 jellybeans, but the team eventually arrives at 1. This means that relatively speaking a quarter of football is about the same size as a period of hockey.
Summary
Although ideal developer days are more concrete and easy to understand than relative task size there are a number of drawbacks to the approach. I favor relative task size because improvements in the team dynamics, technologies, and practices are be reflected in velocity. With ideal developer days velocity does not reflect these improvements and we can mistakenly believe that the team is not getting better.
How does relative task size reflect technology and team improvements in velocity? Let’s look at a simple example:
Using ideal developer days we estimate the following: TASK1 - 1 jellybean, TASK2 - 4 jellybeans, TASK3 - 3 jellybeans. The total is 8 jellybeans. Let’s assume that we’ve measured the teams velocity over time and the team can accomplish 8 jellybeans of work in one sprint.
Now let’s step one year into the future. We have some new technology available that makes the same type of work very easy. Using ideal developer days as our estimation technique we estimate 3 similar tasks (these are not the same, but they are similar to TAKS1-3): TASK237 - 1, TASK238 - 1, TASK239 - 2. If the teams velocity hasn’t changed we will obviously have to add a few more tasks to top it up to 8 jellybeans. The problem with this is that it can appear that the team is holding at a velocity of 8 jellybeans, which does not account for the increase in performance. Had we used relative task size to estimate these instead, we would have seen that TASK238-239 receiving similar estimates to TASK1-2 regardless of the technology improvement and the additional tasks the team is able to accomplish would cause the measured velocity to increase.
