One of the primordial concerns of many managers is to be in control of their projects. Everyone knows that projects have a great risk of running out of hand, either in terms of time or in terms of budget. Lean & Agile Project Management delivers such control, faster and better than any other method around.
After just one Iteration, say of a week or two, Lean & Agile Project Management allows you to know quite exactly if your team is going to deliver or not. You know:
- if planning estimates are accurate, or not;
- if you have scheduled enough resources and hours to do what’s needed;
- if you’re using the right method to reach the desired outcomes.
Nearly all other methods produce such information only when the projects approach their estimated dates of delivery.
Lean & Agile Project Management does this trick by making use of User Stories and by playing Planning Poker to estimate the relative weight of these stories. It’s quite hard to define exactly what needs to be done in a project, specially because chances are that wishes, scopes and desires will change over time. Making use of User Stories makes the job a lot easier. A User Story is nothing more than a brief description of one of the project’s results. It’s not specified into major details, it has not undergone a work breakdown process. Yet it’s specific enough for team members to sense how much work it would be to be accomplished, specially as compared to other user stories.
Sensing how much work it would be to accomplish a User Story, is done through Planning Poker. With Planning Poker teams define the relative weight of user stories. The relative weight is defined as the amount of work it takes for a Story to be completed. It’s not about priorities, nor about other expenditure (materials and equipment to be used). It’s only about the amount of work. This amount is estimated and given a neutral figure, a simple number, called a User Story Point. This may for instance be a number from the Fibonacci series (1, 2, 3, 5, 8, 13, 21, 34). Experience shows that teams intuitively know pretty well how much work it takes to accomplish things. Without need to dive into too much detail.
Then they take only one User Story to do a classical work breakdown exercise -on this single story only-: They specify all the tasks to be done to complete the story and also estimate the amount of time it takes to complete each Task, this time in hours or minutes. Then they calculate the time required to complete all tasks for this single User Story. Since they also know how many User Story Points given to the Story, the team can easily calculate how many hours will be needed to complete all User Stories. This amount may then be compared to the available budget.
For instance: If the sample User Story has 5 points and 40 hours of work, then 1 User Story Point represents 8 hours of work. If all User Stories combined have 250 User Story Points of work, then, the total amount of work will probably be around 2,000 hours of work (8 x 250).
This is your first moment of control! Even before the project has started. You will know -already now- if there’s any chance to complete what’s needed within the available constraints. Which will allow you to act right away. If the outcome is that you need to pump up the budget, you can do so -rather then when the project is already underway-. Or you can adjust the method to be applied, or you can reframe your expectations.
But you may want to wait a little while to check if the team has made the right assumptions. This may be a good idea, specially if the team is not very experienced in estimating. Then you make a Release Planning, distributing the User Stories through the Iterations. And you start off with your first Iteration. By the end of the Iteration, you will have your answer. You will know from a real life experience how much time the Team actually needs to complete a User Story Point, or all User Story Points envisioned for the project. So, again you have a chance to act: To adjust the scope of the project, or the level of experience of your team members, or any other way.
If you work with brief Iterations -which we highly recommend- you will have a chance to know all this after a week of doing the work. You’ll be fully in control, you can choose to abandon a project, to adjust or to proceed. Based on evidence. That’s fast, and it’s more than any other method gives you.
Release Breakdown Chart
In Waypoint we’ve added a great Release Breakdown Chart to illustrate this sense of control. This Release Breakdown Chart visualizes the estimated date of delivery, as soon as your team members start ticking off Tasks and User Stories. It lets you know if the team is burning down User Stories as needed to accomplish the goals of the client or contractor. So it allows you to take the right measures. Right away.