Sprint pre-planning guidelines

Agile methodologies are not super effective unless all elements of the process cycle are followed. There are numerous training resources available with many opinions and approaches to Agile methods. This document is a distillation of concepts and provides a brief guideline for teams who want to participate in Agile planning processes for Mobile Toolbox at Sage.

What is Agile?

• Agile development takes advantage of constant feedback loops to make real-time decisions to quickly improve development products.

• Efficiency is gained and dependencies are quickly identified through experiential learning.

• Priorities are continuously evaluated allowing for maximum flexibility to deliver critical components in parallel and in response to changes in the environment.

• Agile development is well-suited for developing and managing complex, fast-moving SaaS products.

What is not Agile?

• Agile is not a replacement for having a strategic plan or understanding the landscape of product delivery or market forces. However, Agile practices do and must incorporate strategic drivers, market forces, and user needs as part of the Agile planning cycle.

• Agile is not a waterfall model where planning, requirements, development and release happen sequentially with one or two yearly releases. Waterfall is an older, traditional method that is better suited to products that are not SaaS based and do not need to respond as quickly to external factors.

What does the Agile cycle look like?

Open

What key tools are needed?

The key tools that are needed for Sprint pre-planning are simple:

1. A backlog collection of stories with enough detail for developers to estimate work effort

2. An agreed upon prioritization method

3. Metrics and disciplined retrospectives

The backlog for pre-sprint planning

Each team involved in pre-sprint planning is expected to come to the table for each iteration with a backlog of stories that they want to include in the upcoming iteration. The stories need to be written from a ‘what is desired' perspective, not a ‘how to accomplish’ perspective. The ‘how to accomplish’ perspective is provided by designers and developers through a design process. A backlog story can be a requirements gathering, design or investigation story to get more information on what needs to be built. Stories should also include acceptance criteria and identify the drivers for the story and who will validate the work in what environment. These criteria can drastically alter the development work estimate. For example, if delivery of a story is expected as a prototype vs. as a functional feature released to PROD, the effort is significantly different.

Prioritization method

Many prioritization methods exist such as stack-ranking, MoSCoW and Kano. Mobile Toolbox most often uses a MoSCoW method to prioritize. MoSCoW is an abbreviation for Must, Should, Could, and Won’t (or Wish).

Must = a key component that makes the product non-functional or hampers development or quality if it is not available

Should = a component that delights users, improves usability, functionality, and anticipates future work

Could = a component we might build if we have time to do it or if external drivers change

Won’t (Wish) = not doing it unless some other change in drivers occurs, or deferred to a later timeframe

Previously, the Sage MTB team has produced a MoSCow output for 6month and yearly planning, starting in Oct. 2021.

The output of this prioritization exercise was presented as the ‘feature planning spreadsheet’, where:

Must = high

Should = med

Could = low

Won’t = deferred

This exercise accounted for factors such as work size, required components, funding timeline, and resource/specialized availability.

Open

Longer-scale retrospectives are conducted by the Sage Mobile Toolbox Team (June and October) to evaluate the completion record against planned. One retrospective output is shown below:

There are downsides to the MoSCoW method, especially when ranking ‘Musts’ against each other. At that point, we may agree to stack rank within Musts.

Metrics and discipline

Metrics are used to evaluate progress and identify improvements and needed changes to Cost, Quality, and Scope. Metrics are assessed at every sprint pre-planning through a retrospective. A sprint retrospective is straightforward and is performed at the beginning of every sprint planning period. It is tempting to skip this step, but it is an integral part of the cycle and must occur in some format.

A retrospective asks simple questions of each participant:

1. What went well in the last iteration?

2. What did not go well in the last iteration?

3. What suggestions are there for improvements for the next iteration?

Traditionally, each person answers the questions on sticky notes and others assign voting points to concepts they agree with. The concepts with the most points are the concepts that are taken up as actions for the upcoming sprint.

Sprint metrics are not yet incorporated into our Jira framework. That effort will be complete at end of May 2023, at which time we will begin to incorporate efficiency data into the sprint retrospective. By doing so, we can more accurately estimate workload and predict when full features will be complete.

Steps to sprint pre-planning

1. Each team brings a backlog of stories to the sprint pre-planning meeting

2. A joint MoSCoW (or other) prioritization method is completed to come up with the desired list of stories for the iteration

3. Sub-teams of Developers then take the prioritized stories and add work estimate points. Any pointing method is fine. Developers must also consider bugs assigned to them, and time for testing and deployment. PMs must consider other overhead and dependencies or blockers. This determines the ‘budget’ of what will fit into the sprint.

4. The joint planning team reconvenes to review the prioritized backlog and the result of the work estimates. If the estimates are higher than what will fit into the iteration, lower priority items are dropped to the backlog, leaving the remaining stories as the final commitment for the sprint.

5. The iteration starts and completes, with the output going into the release cadence, and the retrospective feeding into the next cycle. Traditionally a Scrum Master will run the iteration through stand-up meetings and will be on point to remove blockers. At MTB Sage, we don’t have an official scrum master, but PMs operate in that function.

Q&A

Please drop open questions and in the table