In Manage It! Your Guide to Modern, Pragmatic Project Management, I explained a schedule game called "We'll go faster now." That's the game where the project team thinks they can improve their speed, even though there is no data that says they can.

There's a similar management game, called "Double Your Velocity." Say a team is new to agile. They estimate they can complete 72 points in a two-week iteration. In the first iteration, they complete 30. Ok, they figure out what's wrong during the retrospective, and they complete 55 points in the second iteration. They learn more about their estimation, so they estimate the stories better, and they refine what done means, so they plan for 63 points in the third iteration. They make it! They keep proceeding, and eventually, they settle in at around 67-68 points per iteration.

Now, a senior manager wants to "help" the team. I see this often masquerading as "motivation." A senior manager comes to the team, gives them a pep talk, and says, "I want to see you double your points for the next iteration." Depending on the team, they may ignore the manager, flip the manager the bird, or placate the manager by doubling their points for each estimate.

This is a management velocity game. It's a game, because management can't motivate people to do more work. Teams can see what's slowing them down, remove those obstacles and maybe they can finish more work. But this business of "motivation"? What a bunch of nonsense. (Tell us how you really feel, Johanna :-))

The real problem is when the manager thinks that the placating team has increased velocity based on his or her actions or pep talk. That's when the team might think they can go faster now, or they keep playing with their estimation points.

Velocity is personal to a team. Period. Mucking with the points does not make the work get done faster.

I like tracking velocity for an iteration when I'm using agile. Teams often take several iterations to find their velocity--anywhere from 3 to 7 iterations. That's because the team has to relearn how to estimate, to make requirements user stories, to think about what done means, and how to make their stories smaller. I like estimating in points rather than hours or days, and that can be a challenge for people who are unaccustomed to thinking about relative size rather than duration. (See How to Estimate Without Time Units for a  quick summary.)

I find tracking velocity helpful in these ways:

1. Once we get past the first few iterations, velocity should be relatively constant, unless people are missing. If it is not, that's an indication that something might not be right.
   
2. A decrease in velocity, assuming no one is on vacation or away, may indicate technical debt.
3. An increase in velocity may indicate technical debt because the features are not really done.
4. Or, a velocity increase may be a result of the team revising how they create user stories or estimate.

Velocity changes are not good or bad, they are. And, if you track velocity, you will have more information about the team's progress.

I particularly like to track velocity as a burnup chart.

A client who's trying to move to agile is having trouble with the idea of literally standing at standup meetings. "I get the whole part of keeping the meeting short, but why do we have to stand up? My legs get tired."

I explained that when people don't stand, they are more likely to initiate and jump into sidebar conversations, aka rat-holes. "We don't do that here."

Um, yes, they did. And, we had the video to prove it. We were trying to do a feature-in-a-day, something I often do with clients, to see where the bottlenecks are, and how little they can actually do and still deliver valuable results. We were doing one-hour timeboxes with standups in between to see what was actually going on. We gained a number of valuable insights in our standups:

1. The one-hour timebox was too short. We should have done two-hour timeboxes. But we didn't because not everyone could free their schedules to participate every two hours, so we learned something about their projects and their daily organization.
2. When everyone stood up, the standups were no more than 5 minutes. When even one person sat down, we had tangents and rat-hole discussions.
   
3. They discovered that creating a project on their configuration management system cost them more than 30 minutes. Very interesting.
4. They learned that they had people who were even more specialized than they originally thought.
5. Almost everyone was quite willing to learn what other people do and how to help them.

If you are considering moving to agile, try a feature-in-a-day. And, as you do that, do practice standup meetings and standing up for them.

I'm discussing some engagements with some so-called "Agile" clients. I ask them what they mean by agile, and they say they work in timeboxes (most of the time), and that they have a ranked list of requirements. And, then they say that when the developers are done, they hand off to the testers at the end of the iteration. They don't understand why the testers can't keep up.

Development isn't the only activity that needs to happen in the timebox. Testing, writing, anything else that you need to get to releaseable product is what has to happen in the timebox. That's why agile requires cross-functional teams for the entire duration of the timebox. (I would argue for the entire project.)

Here's an example. Say you're working on a medical device. You have development to do, testing, a little documentation, and the requirements traceability matrix to fill in so you have an audit trail. You would need some developers, at least one tester, a writer, and either that team needs to know how to do the paperwork, or you need someone from the process group to work with the team. At the end of the iteration, you have finished features: tested, documented for the user, and documented for an auditor.

You can't do this without a cross-functional team. But too many managers are concerned about wasting people's time. "But the writer isn't busy the entire time. I want people working at 100% capacity!" Here are some arguments against that kind of thinking:

1. Do you care more about keeping people busy or releasing the product? If you care more about releasing, it won't matter if people are only partially "utilized." They can either help out or think about how to make the rest of the project work easier for the rest of the project team. When people have a little slack time, they can think about how they work.
2. You don't actually know how much time the writer needs to make the documentation correct, or how much time the tester needs to test. People who are not developers are so accustomed to doing the bare minimum (or less), they don't always know what it takes to do a great job.
3. People who are not fully "utilized" can provide early feedback to the others in the team, whether that feedback is about the project or the project's process. The team can catch problems early rather than too late.
   

The cross-functional team optimizes for the project and therefore the product, not the individual. If you are already working in timeboxes, great. If you have a single-function team, add one more function the next iteration. Keep those people there the entire iteration. See what happens. I bet you decide to add any other missing functions for the next iteration.

Don't think you can do agile with a single-function team. Yes, you can work in timeboxes, which is almost always a great idea. But you aren't getting the advantages of agile with a single-function team. You're still pushing the feedback downstream instead of receiving the feedback right away. Try an integrated, cross-functional team. You may be surprised by how fast you can go--or at least, by knowing earlier that you are not going to be able to meet a release date.

I've been working with some clients transitioning to agile. The senior managers want to know when the project will be done.

I can understand why they want to know. But before you start a project, you can't know with any certainty! What you can do is use rolling wave planning to know more as you proceed.

The way to use rolling wave planning for agile is this:

1. Lay out the major features you want in a product roadmap. You can organize the product roadmap by week, month, or quarter. I recommend no longer duration than one quarter.
2. Now, create the stories that go with the features in the order in which you want them done.
3. Work with the team to further refine the stories as they plan the first iteration.
   
4. The team completes the first iteration.
5. Now, assuming the team has worked together before, and that the product owner has refined the user stories as much as possible in the previous iteration, the team takes the time to do a gross estimation of all the remaining features in the roadmap. If the team has not worked together before or is new to agile, they need a few more iterations to practice estimating before they can provide a gross estimate that's at all useful.
6. Lay out, on a timeline, approximately when the team thinks they can finish the features, based on the gross estimate.
7. Now, lay out the major milestones (when you will have finished features) on a timeline. Every iteration, you note what you actually completed. When it makes sense, say every 4 weeks, re-estimate the entire backlog, if you need to provide a more accurate estimate. Since you'll be within +/- a few iterations at the beginning, I don't normally suggest you re-estimate all that often in the beginning. But you could.

Now, you have a rolling wave of what you think you can accomplish when. And, you are closing in on a date for your managers.

I recently led a project portfolio management workshop. Before we started, the senior manager had sent me a lovely spreadsheet with all the projects--all 15 of them. I was concerned. I was sure they had more projects based on our earlier conversations. But, ok, maybe they only had 15 projects.

During the workshop, I asked each of the managers to write down all their projects, one to an index card. We would deal with overlapping projects (people in one group working on another group's project) once we got all the cards down.

They started writing. We got to about 55 projects, including the 15 on the original spreadsheet. That's more what I expected.

Now, they started to rank the projects. Every time they had a question about how to staff a project, the senior manager would pick up the card and "worry" it. He waved it around. He flipped it over, side to side. He put it down. He picked it up.

At one point he turned to me and said, "You know, if we didn't have these index cards, I could have ignored this project now, and not have to make these difficult decisions." He paused for a few seconds, and finished with, "But I get paid to make these decisions, don't I?"

He does. And, now he has the tools to make those decisions. One of the tools is making all the work transparent, which is what writing the projects on index cards does. 

Start with index cards (or stickies) whenever you can, to make the work transparent. Then, if you need to, such as if you have a geographically distributed team, move to some form of electronic too. But remember, the tool will always be a second-best tool.

Index cards have a powerful effect on how we think about the work. The power of the index card is in the way it makes the work transparent to you, and in our ability to easily move them around. Use that power to see and manage the work

As I teach and coach project managers, I'm struck by how many are stuck in command-and-control thinking: I must monitor all the work. I must check in with people to see that they are doing their jobs. I must know all the technical details and make technical decisions about the project. I'm sure there's more.

But that's not the role of the project manager. Nope. The project manager exists to create the path for the project team members to succeed. The way a project manager does that is:

• Select a lifecycle that manages the project's primary risks
• Help the sponsors define what success means
• Help everyone define release criteria
  
• To be aware of and manage all kinds of risks. If those risks are technical and the pm has the capability to manage those risks, then the PM can make those decisions. But it's more likely the PM has to make sure someone on the team can make those technical decisions.
• Protect the team's process from outside influence. If the team wants to improve or change their process, great. If someone from the outside wants to impose something on the team, the PM has to protect the team.
• Allow the team to do the technical work and the pm does the rest-of-the-organization interfacing work
• Help the team see when they are making progress and when they are stuck.
  

Now, there are plenty of things the project the PM needs to do around progress:

1. I like helping people define their inch-pebbles. In the case of an agile team, making sure the stories are sufficiently small. I often discover the team members don't know how to make their work units small enough to see progress.
2. Notice when the team's process is not helping them make progress. For example, a long build time or lack of continuous integration can impede a team's progress. If you're the one enmeshed in the situation ("I have to wait for the build to finish" or "I have to wait for John to check in his changes") you may not realize you are not making progress. In that case, the pm needs to put a structure in place to make those problems obvious. On a non-agile project, I do this with one-on-ones. In an agile project, I do this standup meetings.
3. Make sure everyone knows what is most important to work on now and next. I like ranked backlogs, no matter what kind of lifecycle you use on a project.

So, a PM doesn't need to be the center of the project and control everything. The PM can let the team be the center, and facilitate the team's work.

Every project needs a project vision: the reason the team is working on this project.

When you define the project's value early in the project, the more the project team is likely to tell you whether the project makes sense--or whether you're starting an impossible project. If you can't articulate the vision, chances are good that you're starting on an impossible project, because there's no way to end a project with no vision. A useful vision is compelling to the project team. And it helps the team make decisions about what's in or out of the project.

Here's how you create the project vision:

    1.    Define who the primary customers of the project are. They could be the mass market, existing customers, new customers, or a specific market segment.
    2.    Define the one major focus of the project. This could be a specific feature, or the general approach. If you're new to agile and you're starting a pilot project, you might want to say, "Use agile techniques to see how to adapt them here." A project doesn't focus on five things; it focuses on one overall vision. If your project requirements are too broad to encompass in one vision statement, maybe your project is really a program.  A project has one deliverable. A program has one overall deliverable and is composed of sub-projects, each of which has a deliverable.
    3.    Write as much as you need to, and then edit until you're down to two to four sentences. If your vision is longer than four sentences, you haven't described the project focus yet.

Here's how I do this. With the project team, we decide who the primary customers of the project are. Now, if I know the major focus, I explain it. Otherwise we try to define it together. Now, as individuals, we write our sentences, on stickies. We post them on the wall, and read them out loud, seeing which sentences make sense. We choose sentences and edit. Once we're down to no more than 4 sentences, we are done.

If you're on a project without a vision, stop right now. Take 30 minutes, define it, and get back to the project work. The whole team will benefit, as will your customers.

I teach project management and estimation workshops. Every time I teach estimation, someone asks, "How can we get the perfect estimate?"

You can't. Estimates are guesses. And, if you are multitasking, every estimate you have is wrong. Guaranteed.

But you still need to figure out when things will be done. Instead of estimating how long a task will take, I prefer to estimate how many small things I can complete in a week. And, I make sure I get to done on each task before I take on another task.

One of the problems of estimating large tasks is that we tend to estimate in units that are too large. If you estimate in weeks, you'll be off by weeks. In days, you'll be off by days. In hours, you'll be off by hours. Over the course of a project, even estimating in hours can obscure the actual duration remaining for the project.

Instead of using scope as the base, I use a timebox. Instead of asking, "How long will this take?" I ask, "What are all the small tasks required to complete this piece of scope?" Then I see how many of those will fit into a week.

If you're working with other people, and are using a Delphi method for estimation, you'll discuss your estimate. You'll hear things like "If Danny does it, it's only a 3. If I do it, it's a 5." I always take the upper estimate. Why? Because if Danny is so good, he's not going to be available. He'll have questions to answer or some other task that's a higher priority. I'll do it anyway. And, if I practice doing these tasks I'm not so good at now, I'll get better pretty quickly.

Think hard about whether you want a good estimate or if you want the work done. Estimating at the beginning of the project is often a waste of time. The more work you get done, the better your remaining estimate will be. 

If you want to know how to estimate without using time units, here's how I do it:

For my work, I block out half-day chunks of time. I find that I can do some tasks in that half-day chunk (1, 2, or 3), and finish enough on any one thing that I can safely mark it as done enough and go on to the next task.

Some days, I have tons of little things to do: return calls, make lists, prepare to do something. Some days I have larger tasks: write a blog entry, draft a workshop, write a ton of email. Some days I have quite large tasks: draft 1 of a piece of a chapter, draft 1 of an article, draft 1 of a report.

Most weeks, I have a mix of things that are small, medium, and large. I no longer worry or estimate how long any of these things will take. I know about how many of the small, medium, and large tasks I can finish in a week. I can make my lists taking that into account.

If you are a developer or tester or BA or technical writer or a whatever (don't want to leave anyone out :-), you can do the same thing. Here's my recipe:

1. Make sure you've taken any task larger than a half-day chunk and broken it down into smaller tasks. That's why you see draft 1's for articles. I can write a draft in less than a half-day. I can't finish all the editing and have a great article at the end of a half-day. So, I don't try to do so.
2. Be clear on what done means for a particular task. If you don't know what done means, you can't get there. You'll either "finish" without getting to a reasonable stopping point and then you worry, or you can't finish in less than a half-day chunk.
3. Do just that one task until it's done. Commit to it. Finish it.
   

Now you have a little recipe for getting the tasks done. Here's how you apply it to your estimation. When someone asks how long something will take, you look at all your little tasks. Make sure they small, medium, or large, where large still fits in a half-day. You get no more than 10 half-days in a week. How many of these tasks can you do in a week? Add them up, and there you have your estimation without having to define how many hours a given task is.

If you're part of a project team, and want to try this on a larger scale, I particularly like the Fibonacci series (1, 2, 3, 5, 8, 13, 20) for estimating how large and complex a task is. As a team, use a Delphi approach (everyone gets together and as a group agrees on a number. For me, and when I teach my estimation workshop, any task larger than a 13 means "we have no clue and 20 is as good a number as any other number." When you hear someone is a specialist and can finish something earlier,  take the larger of the two values.

Other folks use t-shirt sizing: XS, S, M, L, XL, 2XL, 3XL. I don't like that as much, because, in my experience, teams don't learn to break tasks down enough, and have too many M, L, XL tasks. YMMV.

Now, it doesn't matter if you work in iterations or not. Take a week. As a group, ask "How many of these tasks can we do in a week?" Discuss the question. Arrive at a number you can all live with. You're done!

Remember that estimates are guesses. They are likely to be wrong, especially if you use time-based units. That's because we are either optimists or pessimists and because we never have ideal hours, days, or weeks. Try this and see what happens to your estimations.