When you’re a project manager for a traditional project, it’s easy to write a project charter. You can sit in your office and write it alone, if necessary. You don’t have to involve the team. On an agile project, is that the right thing to do? Should you even use the same template?
Agile projects are collaborative. You might not have an agile project manager for your team. You might have a ScrumMaster or a coach, neither of whom is a project manager. You might not have anyone who fills exactly the same role the project manager used to fill. But you still need a charter–it helps the team see the vision and the release criteria, among other potential other valuable information. How do you charter an agile project?
Do you know where you’re headed?
The first question I ask teams is this: Do you know where this project is headed? I don’t want to know about this iteration. The team might have an iteration goal. I want to know if they have a vision for the entire project.
If you are transitioning to agile, you might have a project that has to fix some technical debt and a number of defects. Do you want to call that vision “Fix the debt project”? I don’t think so. It’s true, but it doesn’t “wow” anyone. It doesn’t explain why you are doing the project and why anyone should care about doing the project.
Instead, a vision such as, “Technical debt payoff to make everyone’s lives easier by 10 hours a week” does have a wow factor. If you add a dollar figure (the number you calculate from time spent waiting for broken builds and cost to fix a defect), you create excitement and energy for this project. That’s the difference between a yawn and a compelling vision. The vision has to last for at least one release of the software. If you are lucky, it will last for more than one release…but that depends on your project.
How do you write a compelling vision?
You write down everything you know about where the project is headed. Now, think about the people who will use the product. You don’t have to create personas, although that might be helpful.
When you change the focus from you, the company or the product developers to the buyers/consumers of the product, you change your perspective. In this case, the future customers, future product development teams and the organization all win from completing this project. The future customers win because they will be able to obtain products earlier, the product teams won’t pull their hair out and the organization won’t be paying for waste.
That perspective allows you to create a compelling vision for the product. Brainstorm to generate enough words or sentences that you have a rough draft of a vision. Finally, edit. When I do this with teams, it takes us about 20-30 minutes to generate a vision. I suggest time-boxing this activity to 30 minutes. If you don’t have a finished vision in 30 minutes, it’s okay. Leave what you do have up on the wall. Return to this activity another day, and let this one percolate in the team’s mind for a while.
How do you know when you’re done?
Every project team needs to know when the project is done. You might say the project is done when there is no more value in the product backlog. However, if you have release criteria for the project, you might achieve project done-ness earlier than you imagine.
Release criteria are the vital few criteria by which we will judge the done-ness of the project. I try to make them a balanced scorecard. If they are only about quality, the testers will own them. If they are only about date, the managers will own them. If they are only about features, the developers will own them.
Maybe your only criterion is a date. “We will release this product on September 23, 2013.” If that is your criterion, fine. Startups and products in an early market often have criteria like that. That’s because they need to make money and the date is critical. If you have SaaS (Software as a Service), you might have a daily release schedule or something even more frequent. In that case, you might have other criteria, or team norms such as:
- Our main trunk is always releasable.
- We eradicate defects as we discover them.
Teams use the vision and release criteria to make tradeoffs as they proceed throughout the project. The vision and release criteria alter decision-making.
You might need more for a charter. The vision and release criteria are the minimum necessary for a charter. I like assessing the release criteria each iteration to see if we are done. Sometimes, the product owner likes to add more features and grow the project past the criteria. (I know, that never happens to you!)
What do the sponsors want from this project?
One of the things I like to add in a charter is the decision table about what the sponsors want. I don’t know about you, but I often work with project sponsors who want it all: a project that takes no time, has no budget, delivers a gazillion features, with no people. Sound familiar? If so, you might like the project pyramid and the project driver matrix.
I use a project pyramid to help my sponsors walk around the project constraints and help rank the project driver matrix. I explain that often, the organization thinks they have fixed the people, cost and desired date. However, agile provides us an opportunity to change scope often, because we finish features. And if we use the technical practices (part of the environment), we will have fewer defects.
It is up to them what drives the project. The project sponsor needs to answer these questions; if it’s the end of the project, what do you want first:
- To finish all the features?
- To fix all the defects?
- Or to ship the darn thing?
Project Driver Matrix (from Manage It! Your Guide to Modern, Pragmatic Project Management)
|Cost to release|
|People and their capabilities|
Now you know what the first priority is and how you will make tradeoffs when it comes to risks. This will help the team and the product owner make decisions.
Who asks the questions?
If you don’t have an agile project manager, who will ask these questions? This is an impediment the team needs to address and resolve. Some of you can ask the product owner, who will have the answers. Some of you will need to appoint someone to ask the sponsor. And, some of you will have to play rock-paper-scissors or pull straws to decide who asks the sponsor…but you need to ask the sponsor.
Chartering helps the project start and end
If you’ve never chartered a project, consider it. Even if you have a project partly underway, consider it now so you know when to end. Charter the project with the team. Sure, use the same template. Make sure you include the vision and the release criteria, because agile projects start and end just as more traditional projects do.
Every project needs a charter. Use a charter to start and end on track.
If you would like to try the charter, go to Manage It! Your Guide to Modern, Pragmatic Project Management, and download the all the templates. The charter is included.