In earlier posts (Virtues of Minimum Marketable Releases and Kanban Improved via Theory of Constraints) we’ve seen the rationale for using Minimum Marketable Releases (MMRs). They can be seen as “fixed-scoped” mini-projects; but there is a better stand point in considering them as “targeted-scope” or “committed-scope” work packages. The whole idea is that a team commits to deliver the agreed upon scope (much like there is a Sprint commitment in Scrum).
In this post, extracted from Hyper-Productive Knowledge Work Performance, we will see how the same MMR is actually an instrument that can also be used to manage any extra work that might hit the team.
When considering a MMR as a target-scope mini project, we insist on the importance of getting the scope just right, as an act of balancing minimality (to ensure time and money are not wasted) and marketability (to ensure there will be a customer willing to pay for the effort). If the needs and available resources are assessed correctly, such a balance is relatively easy to reach; often it is just a matter of all stakeholders actually agreeing. Therefore, once again, the importance of the noble patterns of Unity of Purpose and Community of Trust is prominent.
The intention to not change the scope of an MMR is also dictated by another important need — that of keeping the team focused on the work at hand, to stick to the commitment in other words. One of the original precepts of Scrum is that a sprint cannot be interrupted by management in order to change the sprint backlog. The reason is precisely to allow the team to focus on a work package (which in Scrum is whatever fits inside a Sprint), and work on its delivery undisturbed. The same principle applies to MMRs as well — if possible, you do not want to disrupt the work on an MMR. However, the real world is a place full of variation and surprises. At times, the change of reality or the change of our understanding of reality (because new information becomes available, or new insights are gained) really requires changing what is being worked on.
While an MMR is a targeted-scope work package in principle, in practice it is possible to change what goes into it during due course. The only caveat is that one needs to recalculate the average flow times and then resize and reposition the buffer, as illustrated in the following figure.
The figure shows the increase in scope as a stair step in the horizontal line that represents the committed scope to be delivered. The recalculation can be done with reference to the original throughput used when the MMR was first defined (as shown in the figure); or more accurately by using the actual throughput measured on that MMR up to the point when the new scope is added. Naturally, just as scope can be added, it can also be removed; and again the buffer needs to be resized and repositioned.
Things become tricky if the due date of the MMR is fixed, too. This is where the quality of the decisions become important; in particular, if the MMR was started soon enough and planned with an initial throughput reliable enough to make the buffer sizing good enough to protect the fixed due date.
Even when there is a fixed due date, it is possible to accept additional work. However, in this instance, the buffer cannot be resized or moved, because otherwise its protective function with respect to the due date would be compromised.
So how can you accept additional work when there is a fixed due date. You let the buffer status decide. If the buffer status is green, there is capacity to handle extra work. If it is yellow, it becomes a balancing act and a judgment call — you might be able to take on the extra work, but the risk is higher. If the buffer status is red, no extra work should be accepted, and it should be postponed for inclusion into the scope of the subsequent MMR.
If, as in this last instance, reality is harsh and dictates that the extra work must be done no matter what, then you can use more sophisticated economic approaches to decide what should have priority. (For instance, cost of delay, sequence adjusted net present value, and throughput octane are all valid approaches.)
Management of Unplanned Work
Work that needs to be done can be classified in various ways. For instance:
-
Business work: this is work that you would typically include in an MMR on the basis of the marketability criteria — work that is needed to make paying customers happy.
-
Internal work: this is work for which you need to have a functional infrastructure in place — for instance, paying off technical debt falls into this category.
-
Change work: this is work you do in order to improve the processes, and optimize the whole system. This is the sharpen-the-saw kind of work.
All these kinds of work can be envisioned and planned for. If they have to be performed by the team working on an MMR, then they should become work items that are included into the committed scope of the MMR. The progress on such work should always be reflected by the buffer status of their corresponding MMR.
There is yet another category of work, which creates problems:
- Unplanned work: this is work that is of a compulsory and immediate nature that you could not possibly foresee. This is Murphy’s work. The typical example is failure demand, that is, problems that arise from a live system encountering critical bugs that need to be addressed immediately, no matter what.
While it might be tempting to add this unplanned work to the scope of the MMR, it is better not to do so. All such work should be managed by a separate and distinct backlog, with distinct metrics and charts. In sophisticated applications, you can use buffer management on that set of work, too, though it is not strictly necessary, precisely because of the urgent nature of the work (it has to be done “ASAP” — no matter what)
Naturally, taking attention and effort away from the MMR to work on unplanned work will affect the MMR’s odds of successful delivery. This will be progressively reflected by the buffer status. If in the daily standups the buffer status keeps on worsening, the reason will be evident — it is the extra, unplanned work that is hitting you. (You can record this in a reason log, and then use it as explained in Hyper-Productive Knowledge Work Performance to hunt down common cause variation.)
What is more important is that you keep track of all unplanned work that has been encountered during the delivery of an MMR. At the end of the MMR, the ratio between the number of delivered unplanned work items and the number of delivered planned work items (those in the MMR), will give you a precise idea of how the unplanned work impacts and loads your team. You can use that as a key metric; you want to see that ratio decreasing all the time, and hopefully get it as close to zero as possible.
Let us examine an example. In the following figure you see a burn-up chart with buffer zones of a challenged MMR (green at the top, then yellow, then red, because the buffer is represented directly on the burn-up chart and not with a fever chart).
Apparently the team is underperforming, as the delivery is almost constantly past the red buffer zone. But is it?%}
The burn-up line (the darker line) is almost constantly in the “gray” area beyond the red buffer zone. While the scope of the MMR (the lighter line) increased somewhat, that scope increase alone did not explain why the project was having such problems. The burn up was flat at the beginning. The reason was that the team was being hit by external events that deflected all resources to investigating, debugging, and fixing live issues. The work on the MMR was not progressing while the team was all busy taking care of this unplanned work. In fact, during the course of the MMR you can count five or six instances when the team had such problems (you see it clearly any time the burn-up line stays horizontal for more than a couple of days).
The unplanned work was managed with a separate backlog, as suggested previously. The additional information provided by such a backlog can be visualized by adding three more lines to the chart. In the following figure you can see the three new lines.
By visualizing the impact of all unplanned work, it is clear that the team was working at the expected capacity. The team was not under-performing, but was being hit by a disproportionate amount of unplanned work.
The new line at the very bottom represents the burn up of all unplanned work performed. The new dotted line in the middle represents the burn up of the total work performed by the team (that is the planned work plus the unplanned work). The new line at the very top represents the unplanned work backlog on top of the target-scope of the MMR. As you can see, notwithstanding the few times when the backlog of unplanned work was reduced, the sheer amount of unplanned work was still killing the project, as the burn up kept on staying in the gray area beyond the buffer zones.
However, through this visualization, at the end of the MMR one can conclude two things. First, the team was still working at the expected capacity (the dotted line in the middle was practically always within the buffer zones). Second, the volume of the unplanned work, which can be read as the height between the top two lines in the last figure: at the end of the MMR it amounted to almost 1/3 of all work delivered. In fact, the team not only hit the delivery of the MMR at the last day of the buffer, but did so by doing an extra 50% of the originally committed-scope which came in the form of unplanned work. Well done, team!
With such data, the team was able to negotiate management’s attention and get approval to spend more effort to produce quality work (for instance, by paying back technical debt) in order to avoid or reduce future live issues; and possibly get more resources to cater to the growing need to maintain the existing product in a live setting, in addition to developing new functionality. By keeping track of and quantifying the impact of unplanned work, the team considerably improved communication with the stake-holders, and could provide substantiated reasons to get funding for additional resources (people and time). It is worth managing unplanned work.
For more information about these techniques, please refer to Hyper-Productive Knowledge Work Performance.