Planning the delivery
Together with the product owner the team can plan what they can deliver and by when, this results in the product backlog and the sprint backlog. The team knows how much effort needs to be spent, for example for the next release, based on the estimate (for example in story points) and the team's velocity (number of story points that can be delivered in a sprint). In DevOps, all activities, including QA & testing activities, are planned together, no separate planning is made. There is a lot of choice on how to make the plan and schedule the delivery of features. Incorporating the test plan into this planning is crucial. For more information on test plans see "Introduction to QA & testing topics".
Much has been said and written about planning in literature, especially for software development approaches, about possible planning methods. In this section, we describe some of the most popular planning and prioritizing approaches, that is: two agile planning approaches (fixed and adaptive) and three prioritizing approaches (MoSCoW, WSJF and Kano-model).
Agile planning approaches
When working Agile you can either plan with a fixed release date (often together with an open scope) or with an open release date – rolling wave approach – (often together with a fixed scope, however also possible with an open scope). One of the key principles from the Agile manifesto is to frequently deliver working software with value for the customer. This implies that scope and time are variable, quality is not. This is the starting point for the described planning approaches.
Fixed release date
The simplest model to use for creating a release schedule is to use the approach of having a fixed release date. The team should then work backwards from the release date to determine the content of the sprints and the number of sprints that can be performed within the release. In the figure below the team has divided 13 features over 4 sprints. Of course, the team can decide, during each sprint, to add, take out or move features to the next (or later) sprints. Although the release date is fixed, the scope is not.
Adaptive planning
Adaptive planning is based on a concept called, "rolling wave planning". Adaptive planning considers current information and adapts the content of the sprint(s) to new information through continuous feedback. With each sprint the team will ask: "Given what we now know, what is the most valuable thing we should do in the following sprint(s)?" Adaptive planning is therefore focused only on planning for the next sprint or a few upcoming sprints and not focused on trying to lay out a plan, months in advance.
As with the fixed date release approach, the team can decide to add, take out or move features to the next (or later) sprints. With an open scope, the team will continue working this way. This is the most common situation in DevOps. Within DevOps a Scrum board or Kanban board is often used as a tool (for an explanation of Scrum and Kanban, refer "High-performance IT delivery models"). With a fixed scope, at some point in time there will be a final sprint. When this final sprint will be is not known in advance.
Forecast of features delivery
Let's look at the above figure again. The product owner may find it uncomfortable not to know exactly which features will be delivered and when.
The product owner may have the following questions.
- Which features will be delivered before May 1st?
- When will the first 13 features be delivered?
These questions can be answered based on trendline analysis. Take a look at the burn-up chart with optimistic and pessimistic "delivered features" trendlines (a burn-up chart shows the number of features delivered as a line going up).
Fixed date forecast.
Fixed scope forecast.
The answer to the first question is, on May 1st all of the "green" features will be delivered and some of the "orange" ones. The answer to the second question is, the first 13 features will be delivered sometime between the 1st of April and the 1st of May.
Prioritization approaches
When working with sprints, the work to be performed in the sprint is planned at the sprint planning and created by the collaborative work of the entire team. The sprint planning is usually time-boxed to a maximum of four hours for a two-week sprint. The input to this meeting is a list of items (feature, user stories, anomalies, etc.), the latest product increment, projected capacity of the team during the sprint, and past performance of the team ("velocity"). A Scrum board or Kanban board is often used as a visual aid. This can of course also be a digital version. (For an explanation of Scrum and Kanban, refer to "High-performance IT delivery models".)
Example Scrum board.
Example Kanban board.
Which and how many items are selected from the list for the sprint is up to the team, in collaboration with the product owner. This sounds easy, but in practice it appears to be difficult to select the "right" items. The following section explains several "prioritizing" approaches, selection based on priority (MoSCoW), cost of delay and item size (WSJF), and the degree of customer needs and satisfaction (KANO).
Prioritizing with MoSCoW
At the start of the release, the team doesn't know all the details about the stories that make up the features and the team also doesn't know what other items (e.g. anomalies and new features) may get added to the list. A way to mitigate this unknown variable is through the feature prioritization process. Each feature included in the release is prioritized against the other features of the release. For instance, MoSCoW (Must haves, Should haves, Could haves, Won't haves), which is a simple straightforward prioritization approach that does not consider the amount of work to realize an item. An approach such as WSJF does take this into account.
Prioritizing with WSJF
Weighted Shortest Job First (WSJF) is a prioritization model used to sequence backlog items (e.g., epics, features and user stories) to produce maximum economic benefit [WSJF 2009]. In DevOps there is a continuous flow of value delivery and to "make sure" that this is the value needed, priorities must be updated continuously to provide the best economic outcomes. WSJF is used to prioritize backlog items by calculating the relative Cost of Delay (CoD) and duration (time needed to realize the item). WSJF is estimated as the CoD divided by duration.
In order to calculate WSJF, the team must determine the CoD and the duration as described in the next sections.
Cost of Delay
Three primary elements contribute to the Cost of Delay:
- Business value (BV)
Indicates the importance for stakeholders, but also possible risk (= possible negative impact * chance of failure) that is incurred when the realization of the item is delayed. - Time criticality (TC)
Indicates how the business value decreases as time passes and considers milestones that must be achieved. - Risk reduction and/or opportunity enablement (RR|OE)
recognizes the extent to which this item removes risk in this or a future delivery, or relevant information (for example, needed to make choices in the near future) can be obtained through implementation of this item.
These elements do not have to be calculated in absolute numbers. The team can just compare backlog items relative to each other using the same Fibonacci numbers as used in planning poker (refer to "Estimating the effort"). The relative CoD is calculated as shown below.
Duration
The time needed to realize the item can be difficult to determine. On the other hand, when the team has fixed resources, job size (in story points) is a good indicator for the duration. (If I tile a kitchen wall and the bathroom wall is 4x as large, it will cost me 4x as much time.) Actually, the DevOps team knows how to estimate item size in story points already (“Estimating the effort”), which helps estimating the duration.
Practical use of WSJF
In practice, we can estimate these parameters as follows: create a matrix with one item in each column and one of the parameters of the WSJF formula in each row. In the case of relative estimation, you look at one row at a time, set the smallest item to 1 and then set the others relative to that. Then – per item – divide the CoD by duration (in story points or hours). The item with the highest WSJF is the next most important item. In the example below "Item 3" would be the most important item.
When using this relative estimation, please be aware that if there are large deviations between the numbers for the different rows (for example when business value ranges from 1 to 3 and time criticality ranges from 1 to 8), then setting the smallest value to 1 may result in too little differentiation between the items, so keep an eye on the results of the calculation (especially if the results are rounded numbers).
Prioritizing using the Kano model
Software development and DevOps are all about the customer. The success of a product or service is determined by what the customer thinks of it. It is therefore important that the wishes of the customer are clear. We call this the "voice of the customer". If the wishes of the customer are clear, it is important to find out the wishes that make the difference, and what should be at least in order: priority must be given to customer wishes. This is possible with the help of the Kano model which was created by Professor Noriaki Kano [Kano 1984]. This model helps the product owner and the team to determine expectations, priorities and explicit needs of customers.
The Kano model
In the next figure, the horizontal axis in the model indicates the extent to which a specific customer requirement has been fulfilled and on the vertical axis the degree of satisfaction for the customer.
We distinguish 3 different factors in this model: basic factors, performance factors and WOW factors:
- Basic factors.
The basic factors are so obvious that the customer does not even mention them when asked, although they certainly assume they have been met. If that is not the case, this will result in great dissatisfaction. - Performance factors.
Performance factors are usually mentioned by a customer when asked what they expect from a product. If the product performs better, its satisfaction will increase, if it performs less, satisfaction will decrease. - WOW factors.
WOW factors (also known as "Exciter factors") give the customer a "wow" feeling. These are often subconscious wishes or latent needs. If these factors are missing, the customer does not miss them, but if they are present, customer satisfaction increases explosively.
Effect of time on factors
If the same WOW factors occur more often, they can degenerate to performance factors and eventually even to basic factors. Take cruise control in a car for example: years ago, this was often seen as a WOW factor. It has now become so common that this has degenerated to a basic factor. In DevOps you have to ensure that the basic factors are always in order, continue to work on performance factors and occasionally provide a WOW factor. Customers are then basically satisfied, experience a high service level due to good performance factors and are occasionally truly taken by surprise.
Continue to:
Performing topics explained for DevOps