This installment of our 12-part series on the principles of the Agile Manifesto deals with principle 7. This principle states:
Working software is the primary measure of progress”
In a traditional waterfall development cycle, all the design is done up front and the project features and roadmap are thoroughly defined ahead of time. Work advances through stages and the stage itself is generally used as an indicator of the progress of the overall project.
For some, transitioning to an Agile development methodology causes uncertainty because there are no cut and dry phases beyond the Sprint iterations. In certain organizations, the nature of the product may lend itself to Continuous Deployment, in which case releases can happen on weekly, daily or even an hourly basis, so the idea of a product as a whole being “complete” or in its “final phase” is not really applicable.
As a result, the way Agile measures progress revolves around whether the product is in a working state or not. There are several tools Agile employs to make this less ambiguous than it sounds. These tools are the product backlog, creating definitions of “Done”, and the team’s Sprint velocity.
Within the product backlog all work items are catalogued, grouped and ranked by the team. The number of items contained in the backlog are effectively all the things that are “not working” in the product’s present state. Whether the item represents a new feature or a defect in an existing one, it fundamentally represents the fact that the software isn’t doing something you need it to do and so there is work that needs to be done. Grouping backlog items under epics, stories, tasks or subtasks, does not change this. Either the software fulfills the intent of the task or it does not. It either meets the goals of the epic or it does not. The number of items unfinished (sitting in the backlog) versus the number of items completed is the primary indicator of how close the project could be said to being “complete”.
This brings us to the next tool Agile provides for gauging progress: the “Definition of Done”. As part of sprint planning, each backlog item should have a definition of what it means to call it complete. This is known as a “Definition of Done”. It represents all the things that must be true in order for the item to be considered resolved and deployable. How closely an individual item matches up to the Definition of Done, represents its progress within a sprint and also the product as a whole. You can think of “Done” as meaning “it works”, so either an item works and is in the “Done” column or it does not and is in the backlog or is being worked on. As your software project moves forward you should have more and more items from the backlog that are now working (i.e. “Done”).
Comparing the number of finished versus unfinished items within a product is handy for assessing its present position, however, when we think of “progress” and “planning” it’s also important to know how that position is changing over time. The third tool we will discuss for assessing progress within an Agile project is Sprint Velocity. Sprint velocity is not terribly complicated. It simply refers to the amount of work the team is able to complete within a Sprint. This can then be used to gauge how many more Sprints it will take to work through the backlog. How the backlog items are ranked can differ from team to team. Some may use story points, others may estimate in time increments or complexity, but ideally, the metric should be consistent throughout the project so that relative comparisons can be made. Calculating the sprint velocity allows for the estimation of deadlines and feature readiness and gives a fairly clear indicator of how quickly a team is able to “get things working as intended”.
David Hubbell
Senior Software Engineer
SPK & Associates
