Velocity Archive

5

Relying on Indicators

I just realized I’ve been driving automobiles for 25 years. Do the math and I’m either older than you thought or I started driving earlier than you thought. Either way, I may have surprised you. What surprised me, the other day, was my reaction to an illuminated indicator light on my relatively new vehicle. It used to be, vehicles had very view indicators.  Of course, there was the analog fuel gauge.  I knew how accurate it was by the amount of times I ran out of gas.  There was also the check engine light.  I think I saw a check engine light once, back in 1986, when I simultaneously saw smoke appearing from under the hood of my 1980 Honda GLC.  My point is, back in the day, by the time you saw the indicator light, it was too late.  Fast forward to today and I realize I have half a dozen indicator lights and I’m very aware of them.

Seat Belt:
This indicator normally lights up if I have not buckled my seat belt.  The light is accompanied by a soothing reminder tone.  The result is I usually look around to notice if anyone is looking at me.  I sheepishly click my seat belt and go on about my business.  It happens on rare occasion, much like farting in public.  Either way, it’s embarrassing and hopefully nobody is around when it happens.
Low Fuel:
This warning normally indicates the car is low on fuel and I should get to the nearest gas station. Fortunately, I also have a digital indicator that tells me how many miles I have left. Regardless of knowing how many miles I have left, having the light appear still creates a certain level of anxiety.  I guess it’s merely a flashback from my reckless youth when I never seemed to put more than $5 worth of gas in my car at a time.  The difference is that used to get me more than 5 gallons of gas, compared to about one gallon now.
Check Engine:
This indicator still frustrates me.  I’ve seen this indicator a few times in the last few years.  Each time it was when the car was dead and would not start.  It would be nice if it actually gave me some kind of warning.  I know the car is dead.  If anything, it should be a scull and crossbones.  I’m not a car mechanic.  Therefore, what good does it do to tell me to check the engine?
Tire Pressure:As a result of the Check Engine indicator light, I now have a new car.  It’s full of all kinds of awesome things, like USB, Bluetooth, and a thermometer that tells me how hot or cold it is outside.  But, I have a new indicator light that I’ve never seen before.  Well, not before last week.  It’s a tire pressure monitoring sensors (TPMS) to monitor the air pressure in each of the tires.

So, here I am writing a post about my car and the indicator lights. What’s my point? My point is, the tire pressure indicator illuminated and I nearly got into an accident, trying to get out of traffic and onto the shoulder of the road.  I was suddenly concerned about what was wrong.  I didn’t hear an explosion.  The car was not pulling to the left or to the right.   My gut was telling me that everything was fine but I’ve been conditioned into believing these indicator lights.  I got out of my car and looked at the tires.  All looked fine.  I took the car to the dealer and had them check the pressure.  All was fine.  After a diagnostic test, it was discovered that the sensor was malfunctioning.

Again, what’s my point?  Do you use metrics or indicators on your project that tell you how things are progressing?  Do you think you rely on them too heavily?  Could it be you need to trust your gut more and the indicators less?  Next time you’re measuring your team or project performance against an indicator (or metric), take a moment to kick the proverbial tires.  Don’t just accept the metric as the truth, the whole truth, and nothing but the truth.

Now if only I could get that guy in front of me to notice he’s had his blinker on the last 15 miles.

Popularity: 1%

2

Teaching Agile to a 5-Yr-Old

If you ever thought it was too early to teach your children Agile terminology or good management/leadership skills, you can stop now.  I wanted to teach our 5-year-old son a few new concepts.  If you can teach a 5-year-old, you should be able to teach a 45-year-old….right?  Well, let’s not get ahead of ourselves.  I actually think kids grasp these concepts better than adults.  They don’t have years of baggage to contend with.

Now, let me preface the bulk of my post by saying, that at age 5, I could not read at all!  I think our son’s teacher has done an amazing job of getting the kids in her classroom reading at the level they do.

So, what is our goal?  Our son’s Kindergarten teacher sent home a “by the minute reading log”.  She identified how many minutes of reading she wanted each student to read in a month.  For February, the target was 50 minutes.  At first, our son acted very overwhelmed.

Oh Daddy, 50 minutes is SO much!

I assured him, he had a whole month to get there.  Let’s call this month a timebox.  In the timebox, the teacher wants you to finish as many stories as you can in the time given.  That’s it!  Now, some stories are going to be harder than others.  But, let’s focus on doing a little bit at a time and getting each story done.

To really understand the complexity of these stories, they were written for a 5-year-old.  They only take about 5 minutes to read.  So, each story will equal 5 minutes.  To make it fun, let’s use story points instead of minutes!

The last concept I wanted him to grasp was velocity.  Velocity is the number of story points we can get in the timebox.  Just know, you don’t get credit if you don’t finish a story!

If you look at the “reading log” image, you’ll see our actual total velocity was 120.  The stakeholder in all of this, his Kindergarten teacher, would be happy if our velocity was a mere 50.

What was really exciting was telling our son, by the end of week 2, that he had met his goal.  If the stakeholder is satisfied with the 50 point velocity, I think we will start having a FedEx Day once a week.  Just like my teams, I don’t want to burn him out.  We need to find a balance and a stable velocity everyone can be happy with.

 

Imagine if this was you and your team.

 

 

Popularity: 1%

0

Calculating Initial Velocity On Day Zero

VelocityWhile reviewing proposal documentation yesterday, I noticed the contractor’s predicted velocity rate was pretty high.  Being they are not experienced in using Agile and they haven’t even started the project, I was curious how they were able to calculate such a high velocity rate for the first iteration.  I know how many developers they intend to use and I know their proposed iteration durations.  I’m not going to get into the specifics as to how they estimated features (user stories, requirements, backlog items, etc.).  So, what did I expect?

Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the features successfully delivered in the last sprint or iteration.  What about the initial iteration?

Terms to understand when calculating initial velocity:

[1] Number of Developers – How many developers will you have doing actual work?

[2] Capacity – What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?

[3] Number of Iteration Days – How many work days are in the iteration?

[4] Load (Capacity) Factor - The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period.  e.g. 1/3 = 2.4 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours

[5] Velocity – How much Product Backlog value a team can deliver in one iteration.

Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc.  As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 2.1 ideal developers are available.  Multiply the number of ideal developers by the number of work days to arrive at the total of ideal work days.  These ideal work days will be applied against your estimated features, to arrive at an initial velocity.

(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]

Popularity: 1%