Many organizations face a significant challenge when they commit to delivering products by specific deadlines. These commitments, made to customers, shareholders, the press, government agencies, and others, carry serious consequences if not met, including brand damage, reduced market share, and decreased customer satisfaction.
Meanwhile, we have Scrum teams, sprinting away, looking up to two/three sprints ahead, and only really committing to the current sprint. Roadmaps and long-term planning are not mentioned in the Scrum Guide and the focus of the Scrum events is mostly the current or next sprint.
So how can managers and executives commit to delivering anything definite in the medium to long term? This puzzle has led to many organizations becoming disillusioned with Agile.
But all hope is not lost. In this article, we will look at techniques for aligning Agile frameworks with the world of deadlines.
Stable velocity
The first step to aligning Agile with deadlines is to achieve stable velocity within a team. Velocity is the amount of work that an Agile team gets done in a sprint. Normally it is quantified in story points or work items. (Note that any items in progress are not counted.)
Typically, Scrum teams have anything but stable velocities when they start out. They are often plagued by over-commitment, with no history to support their estimations; no definition-of-ready, etc. However, as teams mature, velocity hopefully stabilizes. Once velocity has been stabilized, teams can predict, with a high degree of accuracy, what they can get done over the upcoming sprints. As such, stabilizing velocity takes us a step closer to aligning Agile delivery to deadlines.
Perhaps even more important is to stabilise variance (the difference between points committed and points delivered). There are valid reasons why velocity could drop in a sprint (e.g., public holidays, loss of a team member, etc.). But if the team is planning well, the variance should be stable even if velocity dips.
For example, when sprints run over a holiday period, say Christmas, the teams are aware that some will be taking time off but can still do Sprint planning while taking into account the reduced capacity. While the velocity is likely to drop, the variance can remain stable.
PI planning
The concept of PI planning (where PI stands for Program Increment) does not exist in the Scrum Guide but has been popularised by SAFe (Scaled Agile Framework) and adopted by many organizations practicing Agile. The idea is that teams and stakeholders meet, typically, once per quarter, to align to a “shared mission and vision.” Teams can plan out what work items they expect to get done over the sprints in the upcoming quarter.
Of course, a team with stable velocity will be able to forecast for the upcoming PI with a high degree of accuracy.
While PI planning typically only focuses on one quarter, there is nothing to stop teams from planning multiple PIs ahead and even building a roadmap. However, roadmaps must be handled with care as anti-patterns are lurking and ready to pounce. To dodge the anti-patterns, let’s take a look at the way traditional roadmaps are built.
Roadmaps built on empiricism
We all know that empiricism is a fundamental Agile principle and one upon which Scrum is founded. But let’s take a step back. What do we mean by empiricism?
In philosophy, particularly in the Theory of Knowledge, empirical knowledge is understood as knowledge gained through our senses and from experiments. In contrast, rational knowledge is derived from logic, calculation, and deduction.
In the waterfall world, roadmaps are typically built with rational knowledge. While there are infinite variations of roadmap building they fall, roughly, into two camps:
1. Working backwards
With this approach, the roadmap is built by taking the product delivery date and working back towards the project start date, adding delivery milestones at reasonable points along the way. These roadmaps tend to look convincing and many commercial projects have been sold using such techniques. But they are, on the whole, a work of fiction. They often lack any empirical evidence that the delivery milestones can be met.
2. Estimation algorithms
With this approach, the product is broken down into features and each feature is quantified using parameters such as number of screens, lines of code, complexity of business logic, calls to the database, etc. These parameters are put into an algorithm and the number of person-days required to build the feature is calculated.
Based on these estimates, a roadmap is built. Underneath a veneer of mathematical certainty, lies another work of fiction, due to the fact that these algorithms are seldom checked against reality. Empirical input is lacking.
As we can see, both of these approaches lack empiricism and, as such, I believe, fail to support effective and accurate forecasting and planning, especially in an Agile environment.
Instead, we can use the aforementioned velocity and variance metrics to create a far more accurate forecast and roadmap.
Hierarchy of work items
When using tools, such as Jira, linking tasks to stories and stories to epics is standard. It is also possible to go to a level above and define higher-level work items, such as initiatives, themes, or capabilities, to which epics can be linked. A theme, for example, would be the parent to multiple child epics.
There is a tendency in the industry for these themes to be rather vague and generic. For example:
- Improve the look and feel of the mobile app
- Improve the reporting capabilities of the tool
For the above two examples, we will never know when the work has been done, and they are not aligned to any time frame.
If we want to better align our Agile delivery to deadlines, we can make our themes more SMART. We can base them on specific and measurable business or product goals.
While the concept of deadlines is somewhat alien to Agile frameworks, product goals are inherent. So why not make our themes an expression of a product goal and express them in a SMART way? Here are some examples:
- Ensure that the look and feel of the mobile app is fully compliant with the corporate UI/UX standards by the 4.2 Release.
- Build the reporting module into the tool by the November release. (This one could be further clarified by some acceptance criteria detailing the required reports).
So if we can make our themes specific and time-bound, we can do the same for the epics and stories that sit below. In this way, our Agile tool (such as Jira) becomes more than just a snapshot of a sprint. It becomes a way of assessing our progress toward a product goal.
Deadlines vs product goals
I mentioned the two ideas — deadlines and product goals — above, so let’s explore the distinction.
Deadlines
Deadlines often sit within a command and control environment. The thinking is that by setting tough deadlines we drive the team to deliver quicker and create a sense of urgency. The tougher the deadline the more the team will be motivated. Then if deadlines are not being met, various punishments can be deployed such as micro-management, a less-than-glowing year-end evaluation, etc.
This type of thinking is hardly in the spirit of Agile.
Product goals
Product goals are defined in the Scrum Guide as “a target for the Scrum team to plan against.” The implication here is that the goal is time-bound and specific, otherwise, how could the team plan to meet it?
Conclusion
Perhaps the worlds of deadlines and Agile delivery will never be fully aligned and probably never should be. However, we have seen here that our Agile frameworks can be more time-bound and specific. They can support long and medium-term planning. The key is to stabilize velocity, conduct accurate and informed PI planning, align work items to product goals, and use empiricism to plan out our roadmaps. However, there is a risk here that we could lose sight of our Agile fundamentals.
No matter what, as the Agile Manifesto says, we should still be able to “respond to change over following a plan” and “welcome changing requirements, even late in development.”
