If you asked 10 people I bet at least 8 or 9 would say they like pizza. I can’t think of anyone I know who doesn’t like pizza at least once in a while.
About 2 years ago, as I was creating an order for pizza delivery, I realized that that $12 pizza was going to cost $25. Delivery fees, taxes and tip drove up the cost. So I decided to do something about it. I decided to make my own pizzas.
I quickly found out that the foundation (ha ha) of a good pizza is the crust, or more accurately the dough. Get that right and chances are good your pizza will amaze you and others.
Understanding the Process
Making the dough is not a complicated process but there is a procedure you will follow. For the recipe I most often use, for a Neopolitan hand tossed style crust, I mix the flour, water, salt, yeast (or starter) and as a pro tip I also add some garlic powder.
Then you let the dough rise for a few hours, split and form into smaller balls and let them rise for a few more hours. Make a pizza and cook or freeze the dough balls at this point. The two separate rise times are also known as initial/first proof and final/second proof.
If we mapped that process onto a Kanban style board it would look like this.
Similarly, work items for software development teams also follow a repeatable, defined process. The level of detail and states within the process will vary across teams and organizations. Here is a rather generic workflow/process.
What is Work Item Age?
I define work item age as the elapsed time from when work began until now. Or, for finished items, it is the elapsed time from work starting until the work completed. For completed work its age is equal to its cycle time.
To make sure I am presenting a correct definition I also asked Claude and Gemini.
Claude: From a Lean perspective, Work Item Age is typically defined as the elapsed time from when a work item is created or enters the workflow until it is completed or delivered.
Gemini: Work item age is the amount of time that has passed from when a work item started until the present moment. Essentially, it measures how long a piece of work has been “in progress.”
Combining those definitions we get a more complete idea of work item age for both on-going (in progress) and completed items.
What we are going to examine most closely in this article are the incomplete work items, those still “in progress”. And a little bit about what extended work item age of completed items might also tell us.
Measuring Work Item Age
For software development work item age is most often counted in days. In my pizza dough example the unit of measure is hours.
In either case, you are attempting to measure how much time a work item spends “in-progress”. The clock starts when work begins on the item and doesn’t stop until the item is considered done. What “Done” means will vary from team to team.
It’s important to not stop the clock even if an item becomes blocked. Blocked time is still elapsed time, the work isn’t done!
Looking at the Kanban boards I illustrate these aging measures as:
The Negative Impacts of Aging Work
In no particular order here are many of the impacts teams may face if they allow work items to age.
- Increased Risk of Obsolescence:
Any type of dough you make with yeast or a starter will go through one or more proofing stages. This is where the dough rises and develops structure. You’ve likely seen pizzaiolos who toss spinning pizza dough in the air as they stretch and shape it. It’s the structure of the dough that makes this possible.
Overproofing happens when dough rises for too long. Overproofed pizza dough can become difficult or impossible to shape as the structure breaks down. It can tear easily rather than stretch. At this point the dough becomes unusable. It’s incredibly important to stay on top of “age” when making pizza dough.
The longer a software work item sits idle, the greater the chance that its requirements or underlying technology will change. This can lead to rework, wasted effort or even the need to discard the work item.
Also consider that the longer a work item ages the more likely it will become blocked.
- Reduced Predictability:
Single item forecasts utilize Cycle Time while Lead Time, in combination with techniquest like Monte Carlo Simulations, is used to forecast multiple item completion & predictability ranges.
Delayed, or slow moving work items, will increase both of these metrics making forecasting less accurate. Your percentage ranges will increase rather than tighten and decrease. You are lengthening the tail rather than trimming it.
This lack of predictability can damage stakeholder trust and lead to missed deliveries.
If you are working to Fixed Dates, such as a new government regulation taking effect on a specific date, the financial impacts of not knowing when to start the work can be severe.
- Increased Technical Debt:
As work items age developers may forget the original intent or the specific challenges involved. This can lead to rushed or incomplete solutions, which contribute to technical debt. Technical debt also accumulates when temporary solutions become permanent.
Growing technical debt will slow down future development and increase software maintenance costs.
- Demoralized Teams:
When work items stop moving it can create a sense of frustration and demotivation within the development team. Seeing work pile up can lead to increased stress and pressure – the mole hill is becoming a mountain. This can impact team morale and further lower productivity.
- Delayed Feedback:
Quick feedback is essential for effective software development. Shortening feedback loops is at the core of Agile practices.
High work item age delays feedback, making it harder to identify incorrect product assumptions and decisions. This can result in costly rework and additional delivery delays.
Delayed feedback also makes it more difficult for teams to learn and improve their processes.
- Reduced Quality:
Teams may rush to complete aging work items resulting in higher defect rates. Coding shortcuts, workarounds or minimal to no testing are common tactics to “get this off the board!”
- Increased Product Debt (completed items):
Remember that for completed work items their cycle time is equivalent to their work item age. Create a cycle time scatter plot of work items completed over the last 3 months. It should look something like this.
Longer cycle time (red oval) can indicate tradeoff decisions to accelerate other work items (green oval). Items get placed “on hold” due to factors such as new defects, priority interrupts or other “shoulder tap” activities. This delays the delivery of what was previously a higher priority item.
These tradeoff decisions create what I call Product Debt. This is similar to creating technical debt by making certain decisions. These are work items delayed (value delayed) due to decisions made to prioritize something else on very short notice.
Agile is about the ability to change direction quickly but not to cause whiplash. Teams can burn out on constant priority shifts.
Visualizing and Reducing Aging Work
Hopefully you’ve come to the conclusion that paying attention to work item age is a good idea. But you might be unsure how to do that.
Whether you are using a physical board or an ALM (Agile Lifecycle Management) tool such as Jira or VersionOne, the goal is to make work item age highly visible.
If you are using a physical board try:
- Writing the start date on the card
- Adding a tick mark on the card every day it is in-progress
- Add a small sticky to the card every day it is in-progress
If you are using an ALM tool try:
- Displaying the start date on each card as a separate field
- Add the start to the beginning of the work item title
- Turning the work item a different color after an agreed upon number of day in-progress
- Send out a report every morning of aging work items
Use any of the above alone or in combination. Use your imagination if none of the above work very well for you.
The point is to radiate work item age to cause action. Here is an article I wrote describing one way to create action.
Additional practices to reduce the amount of aging work include:
- Implementing (and adhering to) WIP (Work-In-Progress) limits – this will force teams to address aging work rather than simply starting something else when a work item stalls.
- Improving Flow Efficiency – examine and measure where in your process work items stall. Are they getting stuck in a queue which is currently hidden within the workflow? Is there a handoff happening within the team which could be improved or eliminated?
- Remove dependencies on outside teams – you can add the skills necessary within the team by training, pairing, hiring or adopting an open source code model. At the furthest extreme review and reform teams to be more fully cross-functional. Another option is to resolve dependent work before this team starts their work on an item.
- A Culture of Finishing What You Started – Scrum puts an emphasis on finishing. Even if you are not using Scrum teams should adopt a mantra of “Stop Starting, Start Finishing”. At daily huddles ask if you can help others in the team finish something already in progress rather than pulling in yet another work item. “Help Your Buddy” is another great mantra here.
While “over-proofed” work items might not always be quite as dire as over-proofed pizza dough, and need to be discarded, there are very negative consequences to both flow and predictability.
Addressing aging work items is one of the simplest and effective ways to improve the delivery of value in your teams. As an added bonus, and desirable to all management of software teams, the predictability of delivery will increase as probabilistic forecasts will improve.
Until next time!
