The rest

Scrum Club - Day 3: Release Planning

Agile, planning, scrumclub

The third meeting of Scrum Club focused on release planning. We practiced a hands-on approach through two case studies on how to collect requirements, gather data about them, make decisions on implementation order and how to deepen the requirements into actual implementation plans. The following is an example of how to arrange the first release planning in a project.

Creating context

At the beginning of a project, it is important to generate a common context and vision. With the leadership of the product owner, the team discusses goals, value propositions and forms a purpose for the project. It is also crucial to define the stakeholders of the project.

Initial user stories/epics

With the context and vision created, everyone on the team writes user stories. The goal is to develop a high-level understanding of the various stakeholders and their key interactions with the planned system (i.e. high-level user stories). The goal should be a broad vision and vertical requirements that do not go too deep into implementation details.

It is preferable to use a card format. A6-sized index cards are great for this purpose. User stories are written in the middle of the card. As physical objects, the cards are easily moved around. It is also easy to collect data and deepen the knowledge and requirements by simply writing on the sides and back of the card.

The focus of this phase should be on brainstorming new ideas and extracting stories from already existing documentation such as concept design. The idea is to diverge the requirements gathering by collecting many - even wild - ideas. Discussion of context and goals should be present, but decisions about what to do and what to leave out should come later.

Gathering data

The next phase is about collecting data and deepening the knowledge surrounding the user stories. Here, a MoSCoW analysis provides a useful tool in order to clarify what is needed in the terms of making the vision something tangible.

The cards are divided into four different buckets titled Must, Should, Could and Won’t. The Must stories are the items that prevent release if not done. The Should stories provide high priority features that should be included in the first releases. These are usually as important as the Must stories, but there is an option to leave them out. The Could features are important, but they can be left out if, for example, the time frame does not allow for implementation. The Won’t features are the ones that will be left out from the first releases, but might be implemented in the future. The Trash can should be self-explanatory.

MoSCoW does not consider the value or risk of the user stories. It only evaluates the consequences of implementing or leaving the user stories out. Analysing value and risk should come next.

Value and risk can be visualised by using poker chips. First, the value is analysed by giving poker chips to team members. (One approach is to give more poker chips to the product owner than to the team members.) By using their gut feeling, team members divide the poker chips on top of user stories according to the perceived value of the card. Next, two sets of chips with different colors are dealt out, where one color represents technical and the other business risk. (Again, one approach to dividing the chips is to give to the team members more technical chips and the product owner more business chips.) These chips are again placed on top of the cards.

This phase gathers data on the basis of essential features, value and risk. This data can be written on the story cards. Next, using this data, the team makes decisions and converges the features into an implementable set of features that will form the first releases.

Making decisions

The collected data can be refined into actual decisions by considering the following diagram:

 The most attractive features are the low hanging fruits in the low risk - high value category. However, these are usually dependent on other features, especially the high value - high risk ones. If there are independent low hanging fruits, these should be made first. Otherwise, a sound plan is to start from the high value - high risk features and move through the low risk - high value ones to the low value - low risk features. The low value - high risk ones are implemented only if they fall into the Must category.

It is beneficial to start from the high risk features as implementing these will test the implementation plan. In the spirit of agile development, by testing and failing early, even drastic decisions of whether to continue or abort are possible.

This data can be elaborated by grouping the user stories into subsequent releases. For example, grouping together the must have cards with high risk ones defines a beta release. By keeping the sizes of the releases as small as possible, the business case behind the project can be validated as early as possible. Further releases are similarly formed by grouping other user stories.

Sprint planning

By converging to a release plan, essentially a high level prioritized product backlog is created. How are the user stories then defined and planned for the implementation level?

The cards can be used as a starting point for collaborative design. The team should meet regularly, take the next prioritized user story cards and start planning by collecting more detailed requirements, discarding unnecessary details, drawing user interfaces, discussing technical implementation and breaking the high level user story into smaller ones. By continuing this process regularly, the next items of the product backlog will be defined in more detail than the ones in later releases. This work can then be used in order to actually produce a sprint plan and a task backlog for the team.

This blog post has outlined one approach for bringing structure to release planning in an agile environment. By starting from a high-level gathering of users stories and moving to more detail when necessary, it is possible to explore even wild ideas before the cost of detailed planning becomes too high. It also promotes collaboration in a meaningful way and forces the product owner and the team to make decisions together.