fbpx
1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

The 12 Principles Behind the Agile Manifesto: Principle Number Seven – The Primary Progress Indicator

Published by SPK Blog Post
on January 24, 2019

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

Latest White Papers

Total Economic Impact for Atlassian Open DevOps

Total Economic Impact for Atlassian Open DevOps

Forrester's Total Economic Impact Study found that Atlassian Open DevOps could net your organization a potential ROI of 358%. Discover an overview of this Forrester research paper below and download your free copy. Forrester Research Into Atlassian Open DevOps Agile...

Related Resources

LastPass Business For Corporate and Client Security

LastPass Business For Corporate and Client Security

At SPK, we want to empower employees to safely manage their own passwords. Additionally, for organizations, we want to enable the enforcement of password standards. Businesses that follow good password standards, such as increased complexity, non-duplicate passwords ...

Why You Should Be Using PTC Windchill As Your PLM Software

Why You Should Be Using PTC Windchill As Your PLM Software

As a manufacturer, you have to be both structured and agile to constantly stay in line or ahead of the industry. You have to deliver quality products that meet the customer’s needs today whilst being future-proofed for tomorrow.  Aside from that, you also need to...

Smarter Engineering For Medical Devices

Smarter Engineering For Medical Devices

Medical devices are subject to some of the strictest design control regulations in the world. And for good reason. U.S. medical devices are governed by the Food and Drug Administration (FDA). In order to meet the high standards, teams must communicate - effectively....