“Double Your Velocity” is an agile schedule game. It’s easy to manage–you double the points you assign to your stories. Whee! You’ve just doubled your velocity. No muss, no fuss.

But let’s understand what management really wants.

What your management wants is for the team to do more in a given time period. That’s why they want more in a sprint, or for the team to become a hyper-performing team. So, let’s look at the project conditions for a hyper-performing team:

1. No multitasking. Management must manage the project portfolio. You can ask your managers to do this. Really, you can.
2. The customer or product owner must rank the features.
3. The project team must already know how to work together. That means you can’t add or subtract people. The team must have already formed, stormed, and have normed. They have to know how to work together.
4. They have the physical infrastructure: build servers, phone lines, computers, whatever that they need, and they know how to use them. Do not underestimate this part. If you don’t have this part, you can’t do continuous integration, for example.
5. The team needs enough people who play enough cross-functional roles: developer, tester, and whatever else the team needs, so that the team can finish its work. I am being vague on purpose. I don’t know what your team needs. It might need a catalyst. It might need a UX person. It might need an almighty DBA. It might need a project manager to coordinate work from other teams. I have no clue, because it’s your team. All I know is that your team needs enough cross-functional roles to get all of its work done so that the stories don’t come back to bite you on the tush.

Those are just the project conditions. Take a look at the project pyramid I have in the estimation series I wrote last year. The project conditions are part of the work environment. If you have a distributed team, good luck moving to a hyper-performing team. Can you do it? Of course. Will it take longer? Yes. Why? Because you have to experiment with your project conditions. Management will have to stay out of the way while you run your experiments.

Now, I am not known for my tact and diplomacy. Here’s what I have said to management: “Velocity is personal to a team, just like weight is for a person. What you need to care about is our feature throughput. You need to care about our demos, not our points. How we manage our velocity is like making sausage. You don’t want to know that. You want to know the results. We want to show you our demos, not our act of creation, okay?”

I’ve had success with that, especially with overweight managers, and those who knew about sausage-making. I’ve had success with that as long as teams had iterations no longer than two weeks.

Why? Because as a team learns and experiments, it is more likely to create smaller stories. It is more likely to swarm around stories. It is more likely to automate more of its testing. It is more likely to pay down technical debt as it proceeds. It is not guaranteed to do any of this. In my experience, it is more likely to do so, because the team members learn that postponing automation hurts. And postponing technical debt hurts. And big stories cost more than little stories. And waiting to integrate costs more than integrating right away. And, informal pairing among anyone is better than no pairing, and and and… Every team learns their own lessons because every team is different.

But just because many of the lessons the teams I’ve worked with are applicable to many other teams does not make them “best practices.” Phht. They are practices that work in a context. They especially work in a business context. And, once management starts focusing on velocity, the business context has changed for a team.

Managers, look at the demo. If you want more out of a team, work on the project portfolio. Decide what is first. If you can’t decide, run the project portfolio as a kanban. I explain how in Manage Your Project Portfolio. Velocity is too-low-level a measure.

Teams, show your managers a product backlog burnup or burndown chart. I also explain that in Manage Your Project Portfolio. And, demo! I suggest a number of other measurements, such as cumulative flow diagrams.

I like velocity for telling us if the project is not going to end. I have those charts in Manage Your Project Portfolio.

Managers, you can ask a team to do more. But you don’t need to see an internal measure like velocity. That’s personal to a team and doesn’t help you make any judgements about what the team is doing.

Encourage the team to experiment. Use cumulative flow, product backlog burnup/burndown, feature throughput, and demos. That’s the way to see if a team is producing.

Do you have something for us to test yet?

We have completed the card

Hi again. I didn’t hear back from you yesterday on this. We’ve already lost a day of status. Please find some time today to send us your status.

Hurry. I need to test!

Hi guys and gals, in the standup you mentioned that you had questions about the requirements. Could you please provide us with details regarding the stories?

Need you to pull some overtime

I don’t know in which order the emails were, but it doesn’t matter. The building part of the project simulation was only 15 minutes.

Jack Vinson brought my attention to an HBR article about when to bring geographically distributed teams together: at the very beginning or after they had been working together for a while. As with all interesting questions, the answer is, “It depends.”

If this team had enjoyed a meeting before they had started working together, they could have chartered the project and worked out roles and responsibilities. They could have worked out how they would have done their standups. They could have advocated for travel money when they were all in one place. They could have measured the value stream when they were all in one place and estimated it when they were not all in one place to explain why they needed more travel. Maybe.

One of themes of our workshop was “measure the value stream.” If you are in doubt about whether or not something makes sense with the way you are organized, measure the value stream. Look for where information flows, and where the delays are, and how long the delays are. Now you have a shot of understanding who adds value to the work products and who does not. Read Wage Cost and Labor Cost when you have a chance.

We had a great time. Too bad you were not there.

Oh, and if you are considering conducting a workshop in the Bay Area, use Elisabeth’s Agilistry Studio. It was a great facility and she was easy to work with.

And, that’s the part where I say, “Whoa, Nellie. How is technical debt not part of a story? Why does anyone care how you take care of the code base? Or the automated test infrastructure base? Why does anyone care how you curate the systems? Aren’t you in charge of your environment?”

There’s often a stunned silence. That’s when I realize that while the outward part of the project or program looks agile, the project culture is not agile.

An agile project culture has an empowered team, a team who knows that they must leave the code base a little cleaner than they found it the day before. A team who knows that they must improve the automation every day. A team who knows the story is not done until the entire story is done, and that includes the automated tests and the automated test framework. A team who knows they have to work together to deliver business value every day, not just at the end of the iteration.

This problem is related to the feature-itis problem on the part of the product owner not wanting to take iteration time to schedule anything other than features in an iteration. If the product owner only sees what code developers can do, and doesn’t look at what test developers can do, the project is not agile. If the code developers are the only ones estimating the backlog, that’s a huge problem.

Here are some solutions:

1. Call everyone on the project “developers.” Or, call everyone “testers.” I call the team the product development team, and everyone on the team product developers. You have to change the idea that one part of the team is responsible for code and one part is responsible for tests and that the two parts do not operate together. The two parts (plus all the other parts) are responsible for moving the features to a cohesive approach to done. The more you reinforce one group is testers and one group is developers, the less chance you have of getting to done.
2. Make sure you have a team definition of done or that you somehow know what done means. It’s not developer-done, or tester-done, it’s demo-worth-done, or release-able-worth-done. I know of some teams that take a while and many discussions to agree on what done means. Discuss it. Don’t worry if you don’t agree right away. Keep discussing it. This discussion is critical to your success as a team.
3. Stop estimating altogether. If you have an item on the backlog larger than something the entire project team can complete in a day or two, break it apart–not into tasks, but into smaller stories of business value. Now, you have as many stories as there are days in the iteration, more or less. Makes estimating much easier. You have more conversations about the stories, and much less estimating time.
4. When you work on the code, wherever you are in the code, leave it a little cleaner than when you found them.
5. When you work on the tests, leave them a little cleaner than when you found them.
6. Have a product roadmap which includes the automation. If your product owner doesn’t want to or can’t own the automation, then the technical people must own the goals and the plan for the automation. But automation is a project. You should have a vision and release criteria. You should adapt to change in that project, just like any other project.
7. As you work on a story, whomever you are, you help out wherever you are. If you are, by nature, a code developer, you start with the code. Here’s a story to illustrate what I mean:

You happen to be Platform Paul and you do some development, some refactoring, maybe some rearchitecture, some unit test development, whatever it takes to make your code work and checked in. Fine, you are done.

You check with Tina the tester. She is having trouble with the system tests. You do not abandon her, saying, “My part is done.” Oh, no no no no you don’t.

You say, “Hey, Tina, what’s going on? What can I do?” She tells you. The two of you work on her automated test framework, refactoring it until it works for the new code you checked in and her tests. Once it works, and her tests work, now the two of you walk over to Willie Writer.

Willie glares at both of you and says, “I keep writing the online help, but you two kept refactoring all afternoon. I keep chasing you two and those guys!” as he pointed to the other two developers. The three of you laugh and then all three of you complete the online help in the next hour.

Willie and Tina and you do a little exploratory testing under Tina’s guidance, because what do you know about exploratory testing? She calls it “session-based testing.”

Now, the three of you check with the other two developers who have finished the GUI and the middleware, and only now do you move the story to done. Because the feature required a little platform work, more middleware, and a little GUI to be complete.

Product owners, if you don’t want to fund technical debt, you will create more of it. You will slow down the rate of creating features. I have example graphs of this in Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.

You don’t have to have the perfect automated test framework, not at the beginning of a project. You don’t know what it is at the beginning of a project. You only know you need one. But you can write a little and refactor it. I wrote a column about that.

And, when it comes to creating technical debt, the one thing you must do is, stop. No matter what, you must not create more. And, if you wander into some code or tests that have technical debt, I do not see how you can be a professional and leave it there. At the very least, you can create a defect report that says, “We have technical debt here.” You know it’s going to bite you on the tush at the most inopportune time.

I am not a fan of “go rewrite the system to avoid technical debt.” But you and I both know that technical debt slows down system development and often slows down system performance. I want to avoid rewrites. I want to clean up as I go. If you clean up every single one or two-day feature, you don’t have to pay a huge price, ever.

I believe that what we measure in agile teams is throughput, the number of features through the team over time. I don’t think we measure productivity, the number of features per person or per team over time.

In kanban, it’s quite clear. We measure throughput. To me, it’s clear in iterations, too. We measure throughput.

The author likes the word “productivity.” I don’t :-) And, the author is a smart cookie. We’re still in tech-edit, and we have more to do, and the author will win, when push comes to shove.

It’s a very subtle distinction. What do you think? Throughput or productivity? Productivity or throughput? Which one?

My husband and I are suffering by the off-by-one-hour time zone problem described by Carmel and Espinosa in their book, I’m Working While They Are Sleeping. One of my Pragmatic Manager readers, sent me an email that said,

“I manage everyday activities with at least 3 time zones, and sometimes 4 (it depends on customer’s location) – and I know what are you talking about in this post. I decided to reply this time to share one additional point, which, in my humble opinion, is worth mentioning in the below context:

Some countries switch to daylight saving time and some do not. Thus, the timezone charts should be updated twice a year (and sometimes more than twice, since in Israel we have “our own” schedule, different from Europe).

For some reason, people tend to forget this fact…”

Well, I knew that the US was moving to DST this weekend. I did not investigate whether Belgium was moving to DST or not. So, Mark and I missed each other last night. We’ll see whether we connect tonight. I do think this is very funny, quite topical, and ironic.

So, I’m human. If you would like to meet more humans, and take a human approach to working more effectively in geographically distributed teams, join  Shane Hastie and me in our geographically distributed teams workshop April 17-18, 2012. We can help you with these and other issues. We would love to have you. The last day for the early registration is March 15. Hop to it!

Sally sends the email to the project team. I take offense at her choice of words, and answer her–ratcheting up the tension. Maybe John steps in to mediate, and we both yell at him–still in email. If he is smart, he backs away, but if he is like most of us, he wades in, and bam, now three of us are yelling at each other–in email. The problem with the email chain is that the email escalates the problem.

This is no way to solve problems in a project. The only way to resolve these problems is to break the email chain.

But what if these people are all many hours away from each other, and don’t easily overlap? That’s when you need someone who is willing to be a “zoner,” someone who is willing to overlap time zones for the good of the project. (See below for a reference for zoner.)

The zoner doesn’t have to be the project manager, but often is, in a more traditional project. In an agile project, you can decide who will be the zoner for a given iteration, and spread the love or pain, as you prefer, around.

The zoner takes responsibility for looking at the entire project holistically and saying, “Hold on. I’d better pick up the phone and call these people, one at a time, and figure out what is going on. It might take me a little while. I might have to stay up late or get up early, but I will talk to people in real-time and understand the problem.”

That’s how you break the email chain.

It’s a form of risk management for geographically distributed teams. It’s not easy. It requires a little patience, the ability to work outside your desired sleep times, and the willingness to pick up the phone.

Are you willing to do so? Is someone on your team willing to do so?

Note: I first heard the term “zoner” from Carmel and Espinosa’s great book I’m Working While They’re Sleeping: Time Zone Separation Challenges and Solutions. I am working on my review of the book. If you are working in a geographically distributed team you should read this book, and I’ll tell you why shortly.

If you want to learn to work more effectively on your geographically distributed team, please join Shane Hastie and me in a workshop April 17-18, 2012. We would love to have you.

In  many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost. It does matter if you have a ranked backlog, if you use an agile approach, or if you work in flow (kanban), or if you use a lifecycle that allows you to finish features (an incremental lifecycle where you integrate as you proceed).

That’s why I don’t get too perturbed when my managers try to fix the schedule and the feature set, and they rank the backlog. They can make the decision to stop the project if we run out of time or money. No problem. We are doing the best job we know how. I don’t have to sweat it. Because what matters is the ranked backlog.

To those of you who have programs, which have large budgets: yes, you do not want to burn through large sums of money without getting value in return. I agree. However, sometimes you don’t know if you’re getting any value unless you start something and have a chance to evaluate it via a demo to know if you’re getting any value. Your mileage may vary.

1. Remember, the project is a system.

We discussed this in Part 1. You have more degrees of freedom than just the feature set or the release date or the cost. You have the people on the project, the work environment, and the level of defects. If you are working on an agile project, expect to iterate on the end date or the budget. You can use rolling wave for agile projects or non-agile projects. Expect to iterate.

Because the project is a system and you will iterate, remember to estimate with confidence levels, both on dates and budgets.

2. Determine your preconditions for estimation

With a ranked backlog and knowing how to rank the vectors of your project pyramid, you can take a shot at a first cut at a date or a budget.

Never assume you know what is #1 for your project, #2 and so on. Ask. Sometimes, release date is #1, sometimes it’s not. Sometimes cost is #1, sometimes it’s not. Just because your manager asks for a release date does not mean that is the top priority. Ask.

If you are agile/lean and you do not have a ranked backlog, you are up the proverbial creek. Do not pitch a fit, but you cannot estimate. Explain that calmly and firmly. To everyone. Sure, you can start the project, assuming you have enough ranked stories for one iteration, or enough of a ranked backlog to start a kanban board. You don’t even have to estimate the project.

Why? Because the order matters. You can use dinner as an example. If you eat dessert before dinner, you might not want dinner. Why bother estimating how long it will take to make dinner if you’re not going to eat it?

In part 3, I suggested these options for when you had some idea of what was going on:

3. Use Timeboxes, Better Your Estimate as You Proceed

If you are using timeboxes, track your velocity and as you gain more confidence in your estimate, re-estimate the backlog and report it as you gain more confidence in your estimate. Go re-read part 3 for the details.

4. Obtain Data First, Then Argue

When you have a decreed end date and a decreed backlog, do not argue first.Do not bang your head against the wall. It hurts your head and does not change the situation.

I love it when the people who are not working directly on the project think they know more than you do. This is why I’m teaching influence workshops this year, in preparation for my program management book :-) This kind of thing happens all the time in program management.

Go re-read part 3 for the details.

Part 4 was all about how to estimate when everything was new:

5. Your Zeroth Best Bet: Wait to Estimate Until You Know How the Team Works

Can you estimate anything without knowing how this team will work on this project? I don’t think so. And, you should hedge your bet by keeping your iterations short.

6. Your First Best Bet: Make Your Stories and Chunks Small

Make the stories small so they are easier to estimate. Make any tasks small so you can estimate them Make the iterations small so you get feedback faster. Small is beautiful, baby. If you have anything larger than team-day task, you are in Trouble.

7. Your Second Best Bet: SWAG and Refine

Ok, you’ll fall for one of the oldest tricks in the book, but see if you can make it work. Estimate with the team, plan on refining the estimate. Please do not allow your estimate to be someone else’s commitment (an agile schedule game).

Don’t forget to read the SWAG No-No’s.

And those are my seven suggestions. Confidence percentages help a lot.

You can use these ideas for dates or budgets. Substitute “budget” or “cost” for “date” and you will see that the ideas fit.

I wish I could tell you there was a magic recipe or a crystal ball to tell you how to determine the unknown from no knowledge. There is not. You need data. But it doesn’t take long to get the data if you use an agile lifecycle. It takes a little longer with an incremental lifecycle. Yes, I will do a series on lifecycles soon.

If you found this series helpful, please let me know. It was a lot of work. If you would like even more about estimation, please see Manage It! Your Guide to Modern, Pragmatic Project Management at the Prags where you can see excerpts or at Amazon
where you can see more reviews. Yes, there is more about estimation. Astonishing, eh?

Your Zeroth Best Bet: Wait to Estimate Until You Know How the Team Works

If you have not worked on a project like this with this team, you have other problems. It’s not worth estimating the entire backlog at the beginning of the project, because the team members have no idea what relative estimation means to anyone else on the team. The team needs to work together. So, ask them to start together as quickly as possible. Yes, even before they estimate anything. They can work on anything—fixing defects, developing the stories for this product, anything at all. You all need data.

Since you have a ranked backlog, the easiest approach might be to start with a kanban board so you can visualize any bottlenecks.  If necessary, use kanban inside an iteration, so you have the rhythm of the iteration surrounding the visualization of the kanban.
If you keep the iteration to one or two weeks, you will see if you have any bottlenecks. The shorter the iteration, the more often you will get feedback, the more valuable your data.

Once the team has successfully integrated several features, now, you can start estimating together and your estimates will mean something. Use the confidence level and re-estimate until the team’s confidence reaches 90%. How long will that take? I don’t know. That’s why you have a kanban board and you’re using iterations. I have seen new-to-agile teams take 6-7 iterations before they have a velocity they can rely on at all.

Your First Best Bet: Make Your Stories and Chunks Small

If you cannot wait to estimate, because someone is breathing down your neck, demanding an estimate, look at your backlog. How small are the stories? Here’s my rule of thumb: If you eyeball the story and say, “Hmm, if we put everyone on the team on this story, and we think we can attack this story together and get it done in a day,” then the story is the right size.

Now, you can add up those stories, which are about one team-day in size, give yourself a 50% confidence level, because you don’t really know, and proceed with “Use Timeboxes, Better Your Estimate as You Proceed” in Part 3.

Now, if someone is breathing fire down your neck, chances are good that no one has taken the time to create a backlog of right-size stories. But, maybe you got lucky. Maybe you have a product owner who’s been waiting for you, as a team, to be available to work on this project for the last six months, and has been lovingly hand-crafting those stories. And, maybe I won the lottery.

Your Second Best Bet: SWAG and Refine

Assume your manager has asked you for a date and you did not get empirical data from the team, but instead you decide to develop a SWAG,  a Scientific, Wild Tush Guess.

SWAG Suggestions:

• If you must develop a SWAG, develop it with the team. Remember, a SWAG is a guess. It’s an educated guess, but it is a guess. You want to develop a SWAG the same way you estimate the stories, as a team.
• Develop a 3-point estimate: optimistic, likely, and pessimistic. Alternatively, develop a confidence level in the estimate.
• When you start with a SWAG, also start collecting data on the team’s performance that the team—and only the team—can use for the team to use to better their estimation.
• Refine the SWAG: Explain to your management that your original date was a SWAG, and that you need to refine the date. I like the word “refine,” as opposed to “update.” Refine sounds like you are going to give them a better date as in sooner. You may not, but you will give them a better date as in a more accurate date.

SWAG No-No’s

• Do NOT SWAG alone. The team gets to SWAG. It’s their estimate, not yours, as a project manager.
• Do NOT let your manager SWAG for you. Unless the manager is going to do all the work, the manager gets no say. Oh, the manager can decree a date, but then you go back to Part 3 and manage the project and re-estimate reasonably.
• Do NOT report a SWAG without a confidence percentage or a range attached.

When You Have a Decreed Date

It’s fine to live with a decreed date—that means you get to manage the features. Now, you have a choice. You can work in iterations or in flow (kanban). Let’s assume you work in iterations for now.

Use Timeboxes, Better Your Estimate as You Proceed

If you have worked on a project like this, with this exact team before, so that you can use this team’s velocity, go ahead and use this team’s velocity and estimate the entire backlog with the team. I would timebox this effort to no more than 2 hours total. It’s not worth spending any more time on it, because your estimate is bound to be wrong. Why? Because this is new work you have not done before.

This estimate is the first date you cannot prove you cannot make. This is your most optimistic estimate. It is not the most likely estimate, nor is it the most pessimistic estimate. Well, unless you are all Eeyore-type people, in which case it might be the most pessimistic. But, I doubt it. I would take that estimate, and say to my manager, “Here is an estimate that I have about 50% confidence in. I will know more at the end of the third iteration.”

The team tracks its velocity for three iterations and re-estimates the entire backlog again, and see what it has for an estimate again, and compares what it now knows with what it knew before. Now, you have something to compare. You now ask the team how much confidence they have in their estimate. Report that to management. Maybe they have 50% confidence, maybe they have less. Maybe they have more. Whatever they have, report that to management.

Repeat estimating the remaining backlog until you get to 90% confidence.

When You Have a Decreed Date and a Decreed Backlog

Some of you are saying, “JR, my manager has also decreed the feature set.” Fine. As long as your manager has decreed the feature set in rank order, you can make this work.

You still need to know in what order your manager wants the features in. Why? Because if you look back at the project pyramid and the preconditions in Part 1, several things can occur:

1. Your customers/manager may not want all the features if you demo as you proceed
2. Your customers/manager may not want to pay for all of features as you proceed, especially if you provide an estimate and demo
3. You are getting dangerously close to having too many fixed constraints on this project, especially if you have a fixed number of people and a fixed working environment. Do you also have a fixed cost? You are in the danger zone! I can guarantee you that something will not be fixed once your management or customers see the number of defects.

Obtain Data First, Then Argue

If the manager has decreed the date and the feature set why are you estimating anything? Get to work! This is when using timeboxes or kanban and determining your true velocity and performing demos is useful to show progress so your management can see what you are doing. They have no idea if their decrees/wishes are reasonable. I don’t think there’s much point in fighting with them until you’ve accomplished half of the ranked backlog or worked through half of the schedule. Once you’ve done half of the backlog or half the schedule, now you have data and can see where you are.

Now you can take your data, and use the previous option and provide estimates for the rest of the backlog with confidence ranges.

When I’ve been the project manager for imposed dates and imposed backlogs, I’ve explained to management that we will do our best, but that we will maintain a reasonable pace from the beginning and when we are halfway through the time and the backlog I will report back to management where we are. Did they want to know where we are a quarter of the way instead, where we have more flexibility?

That changes the conversation. Sometimes they do, and sometimes they don’t. It depends on how crazed the management is. I also protect the team from multitasking (none allowed). I am the Wall Around the Team, protecting the team from Management Mayhem.