The Four Agile Ceremonies

The fundamental goal of the four agile ceremonies is that they collectively tell a story! This story is about delivering value to the customer. This value increment is called the Minimally Marketable Feature (MMF) and must be integrated with the benefits for the performing organization. The resulting benefit management sustained through the value stream mapping is part of the Minimum Viable Product (MVP) and must be aligned to the product roadmap delivered in one or more releases. Consequently, the product roadmap represents the product strategy integrated with the Measurable Organizational Value (MOV) of the business strategy. Therefore, not only the product increments are created, but also valuable lessons are learned. While multiple artifacts are getting created during the delivery of product increment, the story has to emerge through the board that integrates how effectively planning was done and how efficiently increments were delivered. This connection is demonstrated in Figure 1.

Figure 1: Understanding the Context

“Ready State” of a Backlog

One of the prerequisites of a backlog is to be in a “Ready” state. This ready state means the items in the backlog adheres to the DEEP property: Detailed appropriately, Emergent, Estimable, and Prioritized. It is pivotal that the Product Owner and the team collaborate on creating a healthy product backlog. Based on my personal experience, I recommend that the backlog is filled with items to feed at least two future iterations. Simply put, if we are working on the N^th iteration, a ready state backlog has backlog items conform to the DEEP property for N+2 iterations, as illustrated in Figure 2.

Figure 2: Backlog in a Ready State

While refining the backlog to a ready state, such as from item 4, Spira does not require these items to be associated with any release or iteration. This approach ensures that the delivery team can take part in the release and iteration planning to ensure that they can commit to the work in the upcoming iteration. For instance, a product owner may envision a particular feature to be delivered in a specific release that itself consists of many smaller iterations. While taking part in the release planning, the delivery team may require some technical experiment to be done. Subsequently, additional backlog items can be added from the delivery team’s perspective, which can serve as an independent evaluation of work conforming to the team’s willingness to take on the feature in any specific iteration. If any work at this point requires further refinement for absorption into the next iteration, the opportunity is presented for the product owner to work with the appropriate stakeholder to further refine so that this item can be prioritized into the next iteration. When the requirements are finally ready to be delivered in an iteration, they can be associated with the appropriate iteration within the release.

Roadmap to Release Planning

A release is most frequently associated with a major functionality delivered according to the product roadmap. Alternatively, the product owners may also use the roadmap to align with calendar-based releases if an organization uses yearly, half-yearly, quarterly, or monthly releases. Depending upon the organization’s cadence for releasing functionality, a release may consist of two or more iterations. Some organizations may directly go to iterations if the organizational governance and compliance framework allows such an operating cadence. So, release planning is frequently desired but optionally implemented when agile is adapted. However, iterations are always present. If an organization does not implement releases, then, the iterations still must be mapped to the roadmap.

The relationship between roadmap-release-iteration may be conceptually difficult to understand as many people think releases and iterations are the same or releases are an overhead not required. Yet, another group of teams incorrectly practicing agile framework without any connection to product strategy may be wondering why a roadmap containing product goals is even required. So, let us illustrate with a realistic example. In light of the global pandemic, where the time required to develop a vaccine is questioned or the efficacy of the vaccine for a specific age population or the booster shot is examined, it is good to review the product roadmap, releases, and iterations with a high-level overview of the drug development lifecycle presented in Figure 3 (Rajagopalan, 2019).

Figure 3: Drug Development Lifecycle and Relationship to Roadmap, Releases, and Iterations

Image created and owned by Dr. Sriram Rajagopalan based on his practitioner experience.

In this diagram, several stages such as the pre-clinical trial, clinical trial on a human population, and drug approval process are identified as the product roadmap milestones concluding approximately at Years 4, 9, and 12. These milestones serve as stage gates before product development can continue as part of the strategy. Even in an IT industry where the product may be a software application, such a milestone is required for getting the appropriate funding and approval for product development to continue. So, the product strategy perspective lays the foundation for a product roadmap and subsequent planning.

Now, if one focuses on the first milestone of pre-clinical trials, scientists may evaluate areas like the mechanism of action, channeling the drug to use specific pathways, and understanding the resulting pharmacokinetics. Subsequent to satisfying this need, they may move on to testing the drug with different themes, such as pharmacological and toxicological testing, to ensure that essential organs (such as heart, lungs, liver, etc.) are not getting affected. And, this testing may have to be conducted in various lab animals from mice to monkeys before the results can be compiled for its efficacy to proceed with the testing on the human population, confirming the first human dose. Each such stage is a release by itself. Each release has its own goal (MMF), serving as a micro-stage gate to continuously progress the drug depending upon the success criteria (MVP). When the drug does not meet the required criteria, a decision is made to terminate the continuous research or take a different path aligned with the business strategy (MOV). As one can see, even research & development uses the concepts behind roadmap, release, and iteration.

Therefore, it is imperative that a roadmap exists so that the sequences of releases can be identified and the backlog items are appropriately refined and mapped to the releases and iterations (established in our case, in Spira). This release planning activity precedes iteration planning but serves as a good foundation to ensure that the required stories are in the backlog to deliver on the product roadmap. Figure 4 illustrates this concept in Spira on how five releases are used to deliver on a milestone in the product roadmap.

Collaborating with the team, the product owner may extend the release planning with the continuous backlog refinement activity. This process will help identify any stories from the team’s delivery angle that otherwise would be missed if the release planning is not done. This is shown in Figure 4 below where release 4 is empty requiring work that needs to be done before work in release 5 can start.

Collectively, these releases then unleash the story the product development team must report to the management. For this exact purpose, we have built a number of standard widgets and reports into Spira. Those details are outside the scope of this blog. But if readers want to customize the standard Spira reports, then they should review our blog on the data extraction and reporting in Spira.

Figure 4: Release Planning in Spira

Iteration Planning

Contrary to release planning, iteration planning is focusing on the work committed by the team to be done immediately after planning is completed. It is important to note the keyword – immediately. Generally speaking, iterations are expected to start immediately after the planning is done and the previous iteration ends because the team maintains the operating cadence and also has the context of work already delivered. Like the roadmap is associated with one or more releases, with each release having a goal towards delivering the MVP for the roadmap, the releases are associated with one or more iterations - with each iteration having a goal to deliver the MMF. This is demonstrated in Figure 5.

Figure 5: Iteration Planning in Spira

Daily Standup

The daily standup is where the team members discuss their progress confirming their commitments to the iteration goals. Please note that the ownership is for the team members to discuss the progress. This daily standup is not a status check meeting where the product owner or other team member acts as a status coordinator. The daily standup is analogous to players visiting the waterhole from the example we previously discussed. The main difference is that the team members are the only members confirming completion, impediment, or feedback.

The completion may be recorded on the individual backlog items that move through the various status. Spira provides a robust requirement workflow to facilitate this movement where the assigned owner can mark the status by executing the appropriate transition operation on the requirement. This is demonstrated in Figure 6. Furthermore, Spira’s comment feature (not shown in Figure 6) can also be used to document observations to preserve the context for any decisions made.

Figure 6: Invoking Workflow Status on the Requirement

If the requirement status has not already been updated, the team can leverage the tracking board under the requirement’s panel in the daily standup. The tracking board allows the team to see all the requirements by various statuses. This can be accomplished by selecting the specific release and the status in the Group By section as illustrated in Figure 7. If readers wonder about the background color on the  In Progress lane, this color coding demonstrates Spira’s support for Kanban, where a limit is put on work-in-progress. Readers can follow the Kanban WIP article for more details.

Figure 7: Requirement Status from the Tracking Board

Spira allows options for the tool to be configured to facilitate the automatic status update based on certain events and also do some activities. For instance, as each requirement is “dragged” to an iteration (this is the first part of the iteration planning) in the iteration planning, the status automatically becomes “Planned.” Since teams always break requirements into tasks (this is the second part of the iteration planning after the team commits to a backlog item), Spira can automatically create a default task when the requirement is marked as “In Progress”. Similarly, when tasks or test cases associated with the requirements are updated, the requirement status can automatically move as well. These options can be enabled or disabled in the Planning Option section based on the operating preferences of the delivery team.

Another popular activity that happens in the daily standup is an update on the burn-up, burndown, and velocity charts. Here too Spira comes to the rescue where such details need not be manually tracked. With the requirements moving through the statuses, the charts are automatically updated in the “Requirements Graph” widget for the team to review, inspect, and adapt. This requirement graph is shown in Figure 8 below. In addition, Spira provides numerous widgets to track progress at the project, requirement, task, build, testing, and defect levels.

Figure 8: Requirement Graph Widget

Review

The review is where the team demonstrates the product increment on the work completed. While the product owner can review, accept, and even release the work product throughout the iteration, the review presents an opportunity for the team to demonstrate the functionality. These “show-and-tell” review sessions are recommended for the business stakeholders beyond the delivery team. Based on the product increments delivered, new items may be added to the product backlog. However, the accountability rests with the product owner to accept the work completed or reject it based on the definition of done.

As you may have guessed already, the workflow operations at the requirement level can be used for this purpose (as shown in Figure 9). Here, readers can see the “Mark as Completed” transition operation to move the requirement from the “Tested” state to the “Completed” state. This specific section of Spira allows the product owner to also add comments as appropriate, such as tracking an electronic signature to this approval if the regulatory and compliance nature of the product requires it. Spira allows the transition operations to be configurable with many options for what fields must be required, hidden, or disabled, execution options, notification options, and electronic signature. These configurable options are not shown in Figure 9.

Figure 9: Workflow operation for Completing Requirements in the Review Session

Following the similar workflow approach for requirements, it is also important for the product owner to review the iteration workflow and mark the iteration closed. This iteration closure ensures that only active releases are brought when the team works subsequently in future iterations.

Retrospective

The goal of the retrospective is not to identify the person observing the improvements and suggesting the recommendations but to capture the improvements and recommendations. To facilitate this goal, many techniques can be utilized. Those techniques are beyond the scope of our blog. However, the product owner or an appointed person can document the observations anonymously (e.g., using a survey) or discuss them in a meeting if members are not concerned about anonymity. So, it is recommended to keep a register for lessons learned in a separate Spira product.

In  Figure 10, a new project, “Retrospective” is created where three rich-text-field custom properties are added to the requirement. These properties represent the activities that the team must start doing, stop doing, and keep doing. These activities can be related to a product or process. Subsequently, the backlog in the appropriate Spira product can be populated with requirements related to product and process, brought into the iteration planning immediately, and implemented accordingly.

Figure 10: Handling Retrospective in Spira

Summary

Through these three blogs, we have illustrated how Spira promotes and upholds the basic Agile principles emphasizing transparency, inspection, and adaptation. The Planning Board feature serves as the critical life-saving waterhole in the jungle, and all stakeholders benefit from these Agile principles. At the same time, understanding the role of the backlog items using the DEEP property ensures that the product strategy is aligned with the business strategy.

Agile is not about fierce execution without planning. Agile fundamentally puts a box around the amount of risk that can be controlled by using its timeboxing approach. So, planning for releases to align with the roadmap and then with the iterations, associating backlog items with components and priorities, configuring the requirements through workflows to collect appropriate stakeholder feedback, and tracking commitments through the iteration are facilitated by the planning board and tracking boards.

Spira is a powerful tool and this blog only focuses on the boards it currently has to support Agile approaches to product development and project management. Many functionalities, such as workflow operations, electronic signature, widgets, and customization are mentioned. Readers are requested to consult Spira Documentation and Inflectra extensive knowledge base articles for more information.

References

Rajagopalan, S. (2020). The role of Project Management in Drug Development. Retrieved September 24, 2021 from https://www.youtube.com/watch?v=alxSRZpOJKk