Knowing your metrics

velocity variance

Know your metrics and the behaviors they drive

Everyone at your company should understand which metrics drive the business, and what behaviors they encourage. That's what Joe Nigro, CEO of energy company Constellation, said in a 2016 Harvard Business Review article.  He went on to say, “Everyone needs to know how each metric fits into the big picture…why and how we’re measuring something, and how it’s relevant to performance.”

More directly, I would say metrics should capture the changing environment of your business so you can make informed decisions. But how do you know your metrics are any good?

Encouraging behaviors

If you ask your fellow employees which metrics drive the business, would they know?  Would they care?  I believe their jobs should depend on them caring, though measuring that would be difficult.  If they are unwilling to do their part, perhaps they should "help" some other company.  Everyone should be held personally accountable to understand what helps drive the business and how they can help. If they knew what the metrics are, how could it change their behavior (in a positive way)?

Metrics executives may be thinking about

From an executive level, I can only imagine every CEO (from Joe Nigro of Constellation to your own) start by thinking about these metrics:

1. Topline revenue - Money made from selling goods or services

2. Customer retention - Attracting the right customer, getting them to buy, buy again, buy in higher quantities or at higher rates.

3. Customer acquisition cost - The total cost associated with acquiring a new customer, including all aspects of marketing and sales.

4. Gross margin - Calculated as a company's total sales revenue minus its cost of goods sold, divided by the total sales revenue, expressed as a percentage.

5. Overhead costs - fixed costs that are not dependent on the level of goods or services produced by the business, such as salaries or rents being paid per month.

I hope executive management will help employees understand the metrics that drive the business and why they are important. I hope the employees will internalize these metrics and consider ways to help the company increase revenues, widen margins, or control costs.

One step deeper into the weeds

From a productivity level, be it manufacturing or software development, I think the staff (and the executives) need to understand (and improve) the system of delivery. To this, if executive management doesn't know these productivity numbers, then how can they know when they are making unreasonable requests of the system? A system of delivery in a black box and executives in an ivory tower are not a good combination.  A dissatisfied staff can put your company at serious risk, while on the other hand, a satisfied and productive staff can help drive the business.

1. Cycle time - The total time from the beginning to the end of your process.

2. Lead time - Starts when a request is made and ends at delivery.

3. Utilization - 100% being the maximum, it's the act of making practical and effective use of people or things

4. Throughput - The amount of material or items passing through a system or process. What did you get done or delivered?

5. Cost of Delay - The means to calculate and compare the cost of not completing something now, by choosing to do it later.

I hope everyone will think of ways to shortening cycle and lead times while maintaining or increasing throughput. If maximum utilization is how you make the greatest topline revenue, how do you reach that utilization level without breaking your people or machinery?

Another step deeper into the weeds

From an individual level, I believe we are truly personally accountable. Let's ask the first two questions from this post again. Which metrics drive the business?  What behaviors do they encourage?

1. Commitment/Completion Ratio - What have I personally committed to? Am I meeting that commitment?

2. Throughput (Velocity) Variance - Given the things that I've recently completed, am I predictable? Can others make commitments, based on what I do?

3. Confidence Score - How confident am I that I will actually keep the commitment I made?

I hope individuals will be honest about what they think they can do in a given period of time. I hope they will be honest with their coworkers and with management if they don't think they can keep a commitment.

What behaviors do you think metrics encourage?

Image Source: Calculated Velocity Variance via Notion [UseNotion.com]

New Scrum Team Challenges

A while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want? In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you've been doing Scrum for a while. It doesn't talk about things that happen leading up to your team's first Sprint.  It doesn't talk about the complexity of scaling to the enterprise.  It's just vanilla.

I just got back from coaching a new team and I'll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That's where things started to get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we don't know much.

The purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

You're new to Scrum.  You don't have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Again, you're new to Scrum.  How do you know what small enough is?

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Again, you're new to Scrum.  You have no historical data.

Determining Velocity

The velocity of a team is derived by summing the estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.

If you have a new team, not only do you not have a velocity, you won't have any completed work to compare your estimates to and you won't know how many deliverables to commit to.  What do you do?  I think you just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned to do; Act on what you discover.

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.

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!

story_velocity2

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!

feb_reading_log

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.

Calculating Initial Velocity On Day Zero

While 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 items 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.66 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 18.62 development hours are available per day.  Multiply the number by the number of work days in the sprint to arrive at the total of initial work hours.  These work hours will be applied against your estimated items, to arrive at an initial velocity.

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

Ideally, the team should already be formed and stable, so that you can just forecast.  Unfortunately, this whole scenario is faulted. Not only are estimates for team capacity going to vary wildly, but what about the estimates for the deliverables themselves?  I can get pretty good at estimating a level of effort for work that could take a few days.  But the contractor that was noted in this post was estimating a 3-year project.  By the way, if you're curious, the contractor failed within 1 year. The federal agency then exercised their right to not renew their contract for the option years.  The agency then brought in a new contractor with more Agile experience.