Concept: Over the past decade, Earned Schedule has been elaborated, empirically verified, and adopted by diverse industries. During the same period, the Agile framework has become widely used. Earned Schedule for Agile (AgileES) combines the speed and responsiveness of Agile with the accuracy and control of Earned Schedule.
Practice: Agile takes many forms. The form most relevant to Earned Schedule is Scrum. Here are some principles from Scrum that fit well with Earned Schedule.
- Product Vision: The goal of the project. As Ken Schwaber puts it, ”The vision describes why the project is being undertaken and what the desired end state is.”*
- Product Backlog: The Backlog lists the requirements that the project is to deliver. The list is prioritized, and it’s sized. The sizing is done in Release Points (or Story Points or Ideal Team Days).
- Release Points: A numerical value that measures how much work is required to produce a backlog item.
- Sprint: A timebox—a fixed period of time usually one to four weeks in duration.
- Velocity: The expected number of Release Points to be completed in each Sprint.
- Release Plan: A roadmap of Sprints that achieve the Product Vision. The roadmap represents the sized Product Backlog Items (PBIs) parceled across the planned timeline using the number of Release Points and the planned velocity.
- Sprint Plan: Each Sprint is preceded by a planning session which selects the PBIs that are to be delivered in the next Sprint.
- Sprint Tasks: The Sprint Plan includes the tasks required to complete each PBI.
- Daily Scrum: The team meets each day to answer three questions: what was done yesterday, what will be done today, and what (if any) impediments are in the way.
- Ready to Ship: Agile’s completion criterion: a PBI is done when it is ready to ship.
- Sprint Audit: There are three activities generally done at the end of a Sprint: the Review, the Retrospective, and Backlog Grooming. The Review assesses what theteam produced during the Sprint. The Retrospective focuses on how to improve Sprints. Grooming prepares the Product Backlog for the next Sprint.
These principles have implications for the use of Earned Schedule on Agile projects. Before drawing out the implications, here are some additional observations about the Agile approach.
Many Agilists believe that Product Backlog Items (PBIs) should be independent of one another.** The idea comes from Extreme Programming. In the words of Bill Wake: “Stories are easiest to work with if they are independent. That is, we'd like them to not overlap in concept, and we'd like to be able to schedule and implement them in any order.”***
But, it appears that PBI independence is difficult to achieve. Rather than treat independence as a necessity, it is better to say that Agile prefers independent PBIs over dependent ones.****
One thing Agilists agree on is the completion condition for Product Backlog Items. In Agile parlance, they must be “ready to ship”. That makes physical percent complete an ideal measurement for them.
The Release Plan is not just a thinly disguised version of a traditional schedule. It allocates the Product Backlog items across the planned timeline using the number of Release Points and planned velocity. But, it is only one possible way that the project can unfold. It does not dictate the delivery sequence of Backlog Items. Each Sprint Planning Meeting sets the Items for the next Sprint. Each Sprint Audit, specifically the Backlog Grooming, updates the Items remaining for the next cycle.
What, then, is the value of the Release Plan? It demonstrates the feasibility of completing the project in the proposed time. It is not, however, a yardstick by which the schedule is assessed. That is, it is not the Performance Measurement Baseline (PMB). For Agile projects, the PMB is given by the number of Release Points, the planned velocity, and the proposed timeline.
The implications of these principles for Earned Schedule will be explored in the next post.
References
*Schwaber, Ken. Agile Project Management with Scrum. Microsoft Press. 2004, p68. – As quoted in Pilcher, Roman. (2009, January 9).The Product Vision. [Blog post.] Retrieved from Scrum Alliance Blog
**See Wikipedia, Wikipedia INVEST and Scrum.
***Wake, Bill. (2003, August 17). INVEST in Good Stories, and SMART Tasks. [Blog post]. Retrieved from Invest in Good Stories and SMART Tasks.
****Waters, Kelly. (2008, 13 March). User Stories Should Be *Independent*. [Blog post]. Retrieved from All About Agile. |
