Ian Mitchell — June 18, 2019 — June 18, 2019
geralt / Pixabay
“When trying to teach someone a boundary, they learn less from the enforcement of the boundary and more from the way the boundary was established.” – Bryant H. McGill
A few months ago we looked at how teams can optimize flow across the Sprint boundary, a technique which is founded on their ability to make limited and sustainable commitments.
To recap: not all of the work a team plans into its Sprint Backlog necessarily has to relate to the Sprint Goal and the commitment to that goal which team members make. For example, they might allocate just 60% of their capacity to “must have” items that are essential for Sprint Goal realization. The remaining 40% may be split between “should haves” which optimize the goal’s outcome without being critical to it, and “could haves” which although valuable might not relate to the goal at all. This puts the team in a position to use the negotiated scope as a buffer, by means of which unforeseen issues can be handled. In other words, if any requirement has to be “traded out” of scope — perhaps because the team must expedite unplanned and urgent work, such as a defect or outage — then up to 40% of Sprint Backlog capacity can be renegotiated to facilitate the arrangement. The Sprint Goal, which only demands 60% of the team’s capacity, might remain eminently achievable and no team member will be expected to work ungodly hours to attain it.
We also saw that a team can use Monte Carlo analysis to determine what proportion of Sprint Backlog capacity really ought to articulate to a joint commitment such as a Sprint Goal. Limiting that capacity to 60% is of course nothing more than a rule of thumb frequently applied in the industry, most notably perhaps by those who have had exposure to DSDM. We looked at how, when that percentage is thought to be sub-optimal, teams might run simulations using actual historical data to come up with a better figure.
This provides a team not only with the means to define the commitment they can reasonably make concerning the work on a Sprint Backlog, but also a means to optimize flow across the Sprint boundary. If a Sprint Goal is achieved in good time, any remaining work on that backlog will be non-critical. An unforeseen incident might still occur at some point during the remainder of the time-box, but it cannot put an increment that has already met a release-quality Definition of Done, and satisfied the Sprint Goal, at risk. Hence any work undertaken in the rest of the Sprint does not imply an escalation of commitment. That work may or may not be done, and it can be renegotiated in order to leverage other opportunities. It might be revised just-in-time so the Development Team can segue into the next Sprint as seamlessly as possible. The achievement of the Sprint Goal can effectively become a trigger for re-planning. The team may, for example, consult with the Product Owner and start work on those items currently at the top of the Product Backlog, using refinement as input. As long as team members have already met their Sprint commitments, there need be no expectation that this work will be completed before the current Sprint ends.
It’s important to appreciate that once the Sprint time-box does end, unfinished work doesn’t simply “roll over” into the next one. Rather, it is re-estimated on the Product Backlog to indicate how much is believed to remain. It’s also important to caveat that no matter how likely it seems that newly started work will be continued in the subsequent Sprint, there is no guarantee of this happening, and a Product Owner is free to reprioritize the Product Backlog at any point. The team could, in theory, enter Sprint Planning a day or two later and find a completely different set of priorities in evidence. The unfinished work they started may be returned to in a later Sprint…or perhaps not at all. Any work begun in advance, and left incomplete, is subject to depreciation, task switching, and other forms of waste. It is therefore started at risk. Yet if Product Backlog refinement is done well, the chances of it not being planned into the next Sprint will be minimized, and the optimization of flow will be proven to be achievable and worthwhile.
Now, if a Sprint boundary becomes largely seamless in terms of the work flowing across it, with certain work started in one time-box only to be finished in the next, then there are implications for how Sprint Planning ought to be conducted. The Kanban Guide for Scrum Teams does not mention the spanning of the boundary, but nevertheless puts the focus squarely on flow, pointing out that “[a] flow-based Sprint Planning meeting uses flow metrics as an aid for developing the Sprint Backlog”. The throughput data obtained from a Monte-Carlo analysis might be one consideration. Others include cycle time and the average time an item spends in progress before closure. An item already started might well have to be planned for completion if its Service Level Expectation is to be honored, for example.
The need for healthy flow will guide and shape the work that is forecast in a Kanban-based Sprint Planning session. Each Sprint Goal will be framed in terms of a rolling workflow, and new possibilities are presented. The functional coherence which a Sprint Goal represents might not necessarily be found in the particular selection of work, but rather in the flow metrics that the Kanban Guide describes. A team might reasonably decide that their goal this Sprint is to improve throughput, or to decrease cycle time, or perhaps to eliminate any outliers in work-item age that threaten a given service level. In other words, a flow-based Sprint Goal could be the imperative to which a Scrum team commits, and the functional outcome that requires their collaboration and focus.
To many old Scrum hands, this shift away from feature-oriented Sprint Goals may seem far too Kanban-like and jarring. Bear in mind however that a coherent Sprint Goal clearly still exists in this scheme, and the Sprint along with it. This is Scrum to the core even though it is a Kanban strategy that is being applied. Both are only minimally prescriptive regarding what teams ought to do. The challenge we face is that a reciprocally greater level of understanding and accomplishment must be expected from team members if an implementation is to succeed.
The heat is turned up further once the actual trigger for replenishing a Sprint Backlog is thought through and re-evaluated in terms of flow-based planning. The more flow is expedited, the less critical the Sprint boundary becomes to the inspection and adaptation of work. A team will gain opportunities to leverage empirical control in a more timely manner, possibly on the basis of continuous delivery. The replenishment of the Sprint Backlog ought to reflect these conditions, and need not be constrained just to a Sprint Planning event, the core purpose of which is to agree and commit to an immutable Sprint Goal. In other words, the Sprint Backlog, which has long been understood to be emergent in Scrum, can be replenished at additional points that are determined by Kanban workflow policy.
We have already considered one such policy – when the Sprint Goal is met, any non-critical work that remains on the Sprint Backlog should be re-planned. If Product Backlog refinement suggests that different items are likely to be taken on in the next Sprint Planning session, then non-critical work can be traded out and potentially more important work negotiated in. The team can thereby make a more timely start on those items, and uninterrupted flow across the Sprint boundary will be facilitated.
As a Scrum Team gains confidence in pro-actively managing work across iterations, an alternative policy can be considered which may better optimize flow. Sprint Backlog replenishment might be performed once the contents are drained to a certain level, a trigger decoupled both from the Sprint boundary and the achievement of the Sprint Goal. This can be a logical progression for teams where the Sprint Goals themselves are becoming more flow-based, and the articulation of priority is shifting away from the likes of “must have”, “should have”, and “could have” requirements in favor of establishing Service Level Expectations. The Sprint boundary now begins to signify a regular heartbeat at which point flow-oriented goals are agreed and validated.
Flow-based Sprint Planning isn’t for every team. Scrum is intended for the development and delivery of complex products, and the framing and meeting of feature-driven Sprint Goals has proven to be a good means of empirically controlling the associated risk. However, the complex product domain is not a binary state, but rather a continuum between a chaotic environment and one which is complicated. Generally speaking, as a product matures, uncertainties are gradually reduced along with the scale of the risk being faced. The complex product starts to become “merely” complicated, and standardized templated change can increasingly become the norm. This has contributed to the pattern — widespread across the industry — of using Scrum for new product development work and switching to Kanban for “business as usual”.
This pattern offers a very simplistic rendering of when feature-driven development might give way to the optimization of flow. Yet in practice, complexity is not reduced in a linear fashion. The evolutionary journey of a product from complex to complicated is lumpy and uneven. A team which switches precociously from Scrum to Kanban will often still face challenges that are best mitigated by a feature-oriented goal, albeit perhaps with decreasing frequency. That’s why it’s useful for a Scrum Team to master flow-based planning. Kanban is a strategy which they can turn to on an as-needed basis, and it is one which does not require them to compromise on using the Scrum framework itself.
Business & Finance Articles on Business 2 Community
(94)
