Tag Archives: scrum

The Scrum Sprint Commitment/Forecast as an Expectation

Estimated Reading Time: 3 minutes

Disclaimer –  I’m a well-known Scrum Sprint Commitment basher. But in the last few weeks especially while processing the Lean Conference Boston Keynote by Steven Spear I have a fresh perspective I wanted to share.

There is no improvement without learning

One of Spear’s key points was that there is no improvement without learning. There is no learning without surprises. There are no surprises without setting expectations. Specifically challenging expectations that will be missed occasionally. See a quote from one of his Harvard Business Review articles about how Toyota really learns:

We argued that Toyota’s much-noted commitment to standardization is not for the purpose of control or even for capturing a best practice, per se. Rather, standardization—or more precisely, the explicit specification of how work is going to be done before it is performed—is coupled with testing work as it is being done. The end result is that gaps between what is expected and what actually occurs become immediately evident. Not only are problems contained, prevented from propagating and compromising someone else’s work, but the gaps between expectations and reality are investigated; a deeper understanding of the product, process, and people is gained; and that understanding is incorporated into a new specification, which becomes a temporary “best practice” until a new problem is discovered.

I got a copy of Spear’s book the High Velocity Edge at LSSC12 and I intend to read it in the upcoming months to try and get more insights into this concept of Expectation-driven learning.

Expectation-driven Learning applied to Scrum

So one way to see the Sprint Forecast is as setting an expectation of how much work is going to be done before it is performed and committing to try working as effectively as we can to try and meet that forecast. Sometimes there will be a gap between our forecast and the real amount of work done, which is an invitation to learn about our real capabilities, our processes and our people and drive new experiments for how to deliver at a higher level. I see this as a healthy use of commitment.

This again explains why a team that meets its forecast each and every time might be a predictable team but not necessarily a hyper-productive team and for sure not a learning team. For learning you need hypothesize that you can stretch yourself a little beyond your current capabilities supported by an experiment for how to achieve that stretch. But hypothesis and experiments have this nature of sometimes succeeding and sometimes failing. So you would expect to sometimes miss your forecast and have to learn something from it. Again, no learning without surprises.

This frame of thinking by the way brings Scrum and Kanban even closer in my perspective. It re-emphasizes how working in a pull system driven by commitment to either WIP Limits or Sprint Forecast are very similar concepts of constraints and expectations – explicit process policies that drive learning. This learning is not less important than the ability to predict delivery outcomes that comes together with working in this pull system.

What can we do different tomorrow morning

Scrum Team? Make sure you set challenging sprint forecast, supported by clear hypothesis and experiments of how  you will reach that forecast while still in sustainable pace. Commit to try. Even more importantly commit to learn if the experiment fails. Remember this is a safe-to-fail experiment.

Working with Kanban? Make sure you set challenging WIP limits, supported by clear hypothesis and experiments of how you will sustain this WIP limit while still delivering. Commit to trying. Even more importantly commit to learn if you need to exceed WIP limits. Remember this is a safe-to-fail experiment.

Note the similarity between the two environments! same phrases chosen on purpose.

Manager? Give your teams permission to experiment. Expect them to experiment. Expect them to commit to trying and learning. DON’T expect them to always meet the forecast/WIP limit or you will slow down learning. Expect them not to ignore their commitments. Expect them to come to you with requests for assistance and ideas how to achieve lower WIP limits or higher sprint forecasts. Expect them to try some of those ideas on their own without any help. Finally and probably first thing to do – Teach them that there is no hyper-productivity without improvement. There is no improvement without learning. There is no learning without surprises. And there are no surprises when there are no expectations.



Do we need Scrum to get to Kanban???

Estimated Reading Time: 2 minutes

I just wrote a lengthy reply on a kanbandev thread about Using Scrum to implement Kanban and vice versa and thought I would share it here, especially so I can tweet it directly and try to spark a discussion about it in Scrum Gathering Atlanta (where I’m currently at…)

I engaged the conversation when Danko said:

Well, another mystery regarding the above is whether scrum is an evolution of kanban (which means you evolve to a point that you can start implement scrum which gives you a lot of effectiveness)
That scrum is only “scripting the way” to kanban (which means at the beginning , the company needs some strong guidelines how to operate and then we can leave scrum and start working in kanban since the “right” mind set was set.
My guts feeling is that the second one is the “right” thing thus at higher level of scrum we start to eliminate the meetings, roles and so on and start focusing on how to do things better while we are equipped with good technical and mind set tools
My take on it is that indeed as teams grow more and more mature they can shed away the scaffolding / learning wheels that Scrum provides and achieve better more effective flow.  But that is not to say they reach Kanban.
Kanban or at least the Kanban Method for change leadership does not define the destination. It is not something you reach. It defines the approach you take on the journey there.
You use Kanban to search for the process that works best for you. ( I recently started calling it the search for process/context fit – like product/market fit in lean startup)
I see Scrum the same way. A different approach to the search though. And scrum having more process and prescription confuses people into thinking it is the destination. I see the current attempt to move from Scrum-but to Scrum-and as a positive way to convey the message of searching and inclusion and emergence more clearly.
From this perspective one can ask whether at the early stages of the search it is more effective to use more perscription/change or minimum change possible. The answer probably is it depends.
But Kanban says to very critically examine every aspect of the change and consider whether it is a must.
I’ve seen teams that accelerate through the low maturity process very fast with Kanban without any sprints/roles. So have many practitioners on other case studies reported here on the list and in the industry conferences.
There are of course many cases of teams accelerating through low maturity using scrum.
As well as (too many) teams/orgs that stay in the base camp of low maturity and never continue the journey with Scrum OR Kanban ( I know a certain someone speaking about that today and next week 😉
At the minimum an understanding of Kanban should drive people to critically consider what is the minimum viable change for their organization when they start. If they choose to include Scrum they should be able to elaborate why and not just because Scrum says so

What do you think?

So what IS Scrumban?

Estimated Reading Time: 8 minutes


3 years ago in Agile Israel 2009 I talked about ScrumBan. The slideshare presentation has been one of most popular ones, and remarkably enough it is the second hit on google when searching for ScrumBan. Go figure… Anyhow from time to time people ask me where they can go look up what Scrumban is and I find myself not sure where to point them for a good brief description. I have a problem with my presentation – it is not aligned with the “Kanban Method” for evolutionary change. It is more applying Kanban together with some Scrum concepts as a mashup. This can be a great process framework for teams starting up (which I want to write about in an upcoming post), but it is NOT Scrumban.

Among-st the Kanban community ScrumBan is the name given to applying the Kanban Method for evolutionary change to a Scrum context. You start with an instance of Scrum and apply the Kanban thinking to it. In this post I will try to give a concise description of how that might look like.

Starting with Scrum

Let’s say you applied Scrum. If it works great you are able to deliver working tested software every sprint, there is sustainable pace, great collaboration, and no feeling of wasted time around the edges. Your retrospectives are about finding impediments and dealing with them, and not about estimation accuracy and commitment woes. If that is the case, I’m not sure you need ScrumBan to help you with the team capabilities. Start looking outside the team for how to improve. Consider using Lean Startup ideas to deliver more of the right things, or DevOps/ContinuousDeployment to shorten the time to market.

Most teams though are not there yet. They are having problems with their sprints. Stories leak out, Software is not necessarily working or tested, and the discussion in the Retrospective is focused on how to calculate the right velocity, what % of time to allocate to surprises, estimation inaccuracies and other such problems. If you are working in or with such a team, ScrumBan can help by giving you a change management process you can use as a guide on your improvement journey.


The basic principles of the ScrumBan Approach

ScrumBan is an application of the Kanban Method, so naturally the three basic principles apply (David J Anderson recently wrote a concise post about the Kanban Method and whether it is a framework or not, you should go read it):

  1. You start with what you do now – That is your Scrum. All the ceremonies, artifacts, roles and responsibilities you are currently using. That is right, You start with everything. The Sprint, Scrum Master, Sprint Backlog, Taskboard, Sprint Burndown, whatever you are currently using.
  2. You agree to pursue an evolutionary approach to change – You understand that things will change over time. You might adapt some of the aspects of Scrum. You might add new practices/policies. You might drop some. The important thing is that you agree to pursue improvement towards a process that is more effective for you, one that will help you meet your business goals more effectively.
  3. You initially respect current roles, responsibilities and job titles – Again, you start with your Scrum and your organization. You don’t change the job titles. Whatever you did so far with your Scrum implementation, that is where you start. You might get some ideas for change when you read about ScrumBan and Kanban, but the Kanban Method is about considering/introducing those changes when they make sense, not as a big change up front.

Core Practices of Kanban applied to Scrumban

After understanding and adopting the basic principles, you start using the Kanban core practices. I will use David’s recent language and elaborate on what they might mean in a Scrumban context

  1. Visualize – make the invisible work and its workflow visible – Some Scrum teams already visualize work and its flow. One of the keys to effective visualization of a Scrum context are making sure you see the flow of backlog items from early requirement to done. It is not enough to visualize the sprint backlog. It is important to make the flow of work into and out of the sprints visible as well, since many teams have difficulties exactly with this aspect. In addition, Scrumban is typically about visualizing the flow of Product Backlog Items (PBIs) or Stories, rather than Tasks. Tasks are created late in the game and don’t flow all the way. Some teams visualize tasks as well, but it is optional.
  1. Limit WIP – implement a virtual kanban system – Once you have a Kanban board visualizing the flow, the next step is to implement a kanban system. This calls for Limiting the Work in Progress, which in Scrum context basically means you limit the amount of PBIs in progress at any point in time. Once the limit is reached, the alternative to starting a new story is to go and help others deal with their story. This can mean helping others in your expertise area or going upstream or downstream to help (e.g. Developers help Testers, Testers help Product Owner, etc.). Limiting WIP introduces pain. The pain of not being able to do what you’re comfortable with and got used to. We want to channel this pain towards ways of improving the team’s process and policies so in the future the flow will be better and the WIP Limit will be less painful. Improving engineering practices, using techniques such as ATDD, Reducing batch/PBI size, Cross-training, or any other technique can be considered as a way to make the WIP Limit more comfortable. Over time as team capabilities improve, the WIP Limit can be tightened to catalyze even more improvement in capabilities. Limiting WIP is a great way to drive real collaboration at the team level.
    Side Note: that the “Sprint Backlog” itself is a WIP Limit – it limits the amount of PBIs that can be started during the sprint unless all of them are finished. It is a shame that many teams and even coaches miss this point. In any case even if you are treating the Sprint as a WIP Limit, Using granular limits on number of stories active during the sprint will help you improve flow even further.
  2. Manage Flow – with the virtual kanban system in play using WIP Limits, it is now time to run the system and manage the flow. Teams start looking at the cycle times of PBIs/Stories for information on where there is room for improvement. They monitor cycle time/aging in real time to see struggling stories and find ways to help them along. They care about the healthy flow of work (which within a sprint is not less important than whether the sprint forecast/commitment is met – but more on that elsewhere). They start using Cumulative Flow Diagrams which add information about the queues within the system to a Burnup chart.
  1. Make management policies explicit – Some scrum teams make their “Team Rules” explicit. This is a similar approach. You make your process explicit. Both so empowerment can happen – people on the Scrum Team cannot be empowered if they don’t know the process. Self Organized teams cannot work if they don’t have a shared understanding of how work is done. But making the process explicit also helps improve. With the “invisible” process now made visible, healthy discussions about “why we do things this way” or “how will changing this policy affect our flow/results” become easier and happen more naturally. Remember that here we are talking about the team’s policies for how it manages itself. Some of the policies might be driven by the organization and require management approval for changes. Many of them will belong to the team and should be evaluated and experimented with actively as part of the Retrospectives.
  2. Improve Collaboratively using models and the scientific method to implement a “guided” approach to evolution. Start treating your Retrospectives as the place to design experiments. With an idea of how something might improve your capabilities, Plan what you aim to test, what will be the validation that you are on the right direction, and in the next Retrospective review the results and decide whether another round of experimentation is necessary (Pivoting) or whether you can deploy the change as a standard operating policy for the team. Use improvement frameworks such as A3 / Toyota Kata for this process. Invite in models like Reinertsen’s Principles of Product Development Flow to understand the interaction of Batches, Cadence, Heartbeat, Teams, Variability, WIP, Cycle Times, in ways you never had before.

What might happen/emerge when using ScrumBan to evolve your Scrum process

So far I just talked about the guiding principles and the practices you follow when applied to the change process. Beyond this point, any more changes to the way you work will emerge from what you discover when you visualize the flow, limit the WIP, make the management policies explicit, and start to have collaborative improvement discussions focused on hypothesis, experiments and learning what works.

You probably feel “cheated” at the moment. Is this all there is to it? Where’s the actual stuff? The changes to the sprint model? What about the roles? One way to finish this post would be to stop here and emphasize the complex nature of each team’s context and how we don’t know exactly what will emerge.

I will risk going a bit beyond that and share a couple of emerging behaviors seen in teams that go on this journey. Not all teams will see the same patterns. And don’t go using these patterns as a recipe book. Doing that might be useful, but it is a different kind of change process. I will write in the future about “Kan-Beat”, “Kan-dance”, “Kan-Bum” or whatever we decide to call the approach of starting a team with a Kanban+Scrum mashup. In the meantime you might get a few ideas for how to design a useful green-field process.

Rolling Finish/Start of Sprints

One of the first things teams realize when they start thinking about flow is that the sprint represents a “Batch Transfer” process. Many PBIs wait to go into a Sprint or get out of it, even though they are ready and could be processed without wait. In addition they realize the requirement to “clear the table” when finishing a sprint and “restart the machine” when starting again is in conflict with smooth sustainable flow. So what typically happens is that the Sprint Cadence becomes more of a heartbeat of rallying points to summarize what happened since last time, think about improvements, and do some look-ahead planning. Think about pit-stops in motor racing. The aim is to minimize the time it takes. If it could magically become one of those “Refuelling zones” in video games where stuff just magically happens to your car while you pass in the zone without even so much as a slowdown, it would be perfect. A word of caution is that some way of maintaining “Sustainable” pace should be used. “Jogging” periods each sprint are only one way to do it. Just be careful not to go into an endless stream of work. After all we are talking about human beings not machines.

Sprint Planning-Lite – Deemphasizing Estimations and Forecasts

When teams understand that limiting WIP is a great way to achieve the focus and fast cycle times, they more often than not ask themselves about whether they still need the Sprint Commitment as a way to focus themselves. Combined with the fact that people exposed to Kanban start to hear case studies and examples of teams that replaced estimations with just ensuring small enough units of work and use cycle-time based forecasting rather than deep up front estimations, they now explore what I call “Sprint Planning Lite” – a ceremony which is more looking at the big picture of upcoming work items and making sure it is a coherent picture and the items are ready, and give a general forecast what will be delivered and a specific forecast for items that are time-sensitive. Typically less time is spent on calculating accurate capacity – a big picture of main capacity changes from last sprint is enough just to have early warning of flow problems (e.g. tester is away for a few days on an Agile Testing workshop). Some teams don’t even look at each specific story in-depth deferring this discussion to the time it will be pulled into work. Some teams do a high level estimation using a lightweight team estimation game to make sure they are aligned on the story implications, and have a discussion only about specific stories. I found this style of planning is like a fresh wind to most teams, so it is well worthwhile trying.



In this post I started by saying ScrumBan isn’t a development process in and of itself. It is a process for evolving a Scrum instance to be more Lean/Flow oriented.

Then I talked about how this change process works by enumerating Kanban’s basic principles and core practices as applied to ScrumBan.

I then added some emerging properties when applying ScrumBan to Scrum. When you apply ScrumBan to Scrum you might end up with some of those or other ones.

It is now up to you, the reader. ScrumBan/Kanban/Scrum are just means to achieve an end. Start with why you need to change anything in how you do things. Visualize the invisible to have a better grasp where you are. Design experiments and validate your thinking on ideas that will improve your performance, pivot away from useless/harmful practices and drive towards what attracts the results you seek.



Go ScrumBan

If you’re interested in some help figuring out if ScrumBan is a good fit for you and how to go about implementing it, AgileSparks can help.


Scrum Sprint Commitment Rant

Estimated Reading Time: 9 minutes

Going on a Rant

If there’s one thing that makes me mad whenever I see it is teams abusing the commitment concept in scrum. I’ve been on a rampage against dysfunctional sprint commitments for a while now, but lately my thoughts have crystalized a bit, especially when I had a chance to discuss this with Jim benson, Alan Shalloway, Chris Hefley and Jon Terry last week at Lean Kanban Benelux 2011.


So what is the problem? Well quite often you see scrum teams that finish sprints out of breath, out of quality, out of joy. You also teams that start the sprint full of numbing fear, set a low bar and that low bar becomes a self-fulfilling prophecy. Add to that Product Owners, Scrum Masters and managers all spending precious time worrying about whether we are able to make accurate sprint commitment, instead of working to improve the actual capability of the team.

It’s quite sad actually. Surely that’s not what scrum should look like and indeed other teams have energized focused sprints where they deliver what they can, stretch their abilities just the right amount and finish a sprint with just the right energy and mindset to joyfully go into the next one.

So what’s causing this?

Well, let’s start with the out of breath teams. It typically starts with unrealistic commitments they make in the sprint planning. They make those commitments either because they’re pushed to do it explicitly or implicitly. Yes, scrum says the team should pull according to their capability. But something about the way this all works de-emphasizes actual capability of the team and motivates them to try to take on more than they can handle.
With this in play, they start and since there is a lot in their sprint backlog they have the green light to start many things in parallel. A few days later, in the last mile of the sprint, it’s still many items in progress and it’s either an unsustainable effort to reach the finish line, cutting corners or having a very disappointing sprint result. In our #LKBE11 discussion we referred to those as mini-death-marches…

With teams living in fear it is a different but related story. It starts with the message/spirit conveyed to them by their Product Owner, managers or previous life management culture. When they hear commitment they hear “miss that and you’re in trouble”. And if the ecosystem is such that meeting the sprint commitment is more important than the overarching purpose of the project/release/feature they will be driven to satisfy what they perceive as important – being predictable at the sprint level. So they make a safe commitment. Usually this is achieved by taking safety in the estimates. And so starts a self-fulfilling prophecy, as described by Parkinson’s law and Donald Reinertsen’s principle of the expanding work.

It doesn’t help that the team thinks that if they are able to deliver more, there is no turning back – from that point on they will be asked to deliver more on a consistent basis.

Lets pause here for a second – Isn’t it a reasonable expectation? Shouldn’t the team commit and deliver more in the future if they’re able to? The problem is that even during a short 1-4 weeks sprint, there’s still a lot of unavoidable uncertainty and variability. In exactly what we need to accomplish (requirement space), in how to do it (problem space) and also in how much time will we have for it (capacity). A lot of teams try to eliminate this variability and spend a lot of effort on it. Planning meetings grow longer, people’s capacity is planned at the micro-level…

Many teams will oscillate between over-commitment and under-commitment exactly because of this variability of course. They and their management will be frustrated if they’re measure for effectiveness is meeting the commitment. The only way to consistently meet a commitment is either unsustainable pace, or making a really safe commitment.

Lets eliminate commitment

Well, just as an exercise for now, to see why it’s there in the first place…

Without a sprint commitment, how will the sprint look like? Probably we will see people taking on work from all over the place. They will start at the top priority, but their nature will lead them to start many other backlog items since there is no focusing force urging them to stop starting and start finishing. So we need commitment, or something else, to encourage a team to focus on a few things and finish them first. An alternative to commitment at the stories level is to say we are focusing on a single feature so let’s finish it before moving on to anything else.

Commitment as a Focusing mechanism

Wait – this is the Scrum Sprint Goal – Teams are supposed to agree on a Sprint Goal they will focus on. The detailed story level commitment is an elaboration on that anyhow. If our product backlog is very fragmented and not feature oriented we will have a tough time using an effective sprint goal though. This is something to wonder about in and of itself… but if it’s indeed the business reality that we are doing many small things, we need another focusing guidance. That guidance can be “we think we can finish at least 8 stories, hopefully 4 more, so lets start with 8, get a good feeling we can finish them, and ONLY THEN move on to the 4 others”. Here, the team is still using the sprint commitment, but they’re using it for themselves as a focusing / work in process limiting mechanism.


Another problem we might have without commitment is that the work will expand uncontrollably. There is no finish line so there is no container. One thing that might help is very energizing purpose of where we need to get at the end of the Feature/Project/Release and why it needs to be at a certain point in time. Seeing our progress towards that goal (or lack of progress…) will help energize our efforts and reduce the expansion of work.

Commit to Capabilities Improvement

Another thing that might help is to start looking at our capability as a team and make a commitment not to exactly what we deliver but in general to improve our capabilities. The capability we care about is velocity as well as ability to turn out the top priority items in the backlog as soon as possible since they are the highest priority. So let’s monitor our capabilities over time and try to make them more predictable first and improve them as a next step. Specifically, measuring Velocity can be done without making any sprint commitment. Just track the velocity for each sprint, preferably on a control chart so you can start to understand the variability in your capabilities.

How can we make promises without commitment?

This is a point I love. On one hand Agile diehards say there is no commitment in agile – “we will just work sprint to sprint and avoid any clear external commitment the business can count on”. On the other hand if you start a discussion about losing the sprint commitment they and others start talking about “how can it even work without the team making a clear commitment and sticking to it?”. Bottom line, the sprint commitment doesn’t help you one bit in making external commitments and meeting them. It’s simply orthogonal to it. You make external commitments based on size estimations and historical/estimated capabilities. You meet external commitments by monitoring where you are towards them and adjusting scope, resources, pace sprint by sprint. If you use the sprint commitment as you should, it gives you nothing towards that goal. Accuracy in sprint commitments is micro-predictability. The business cares about mezzo/macro predictability. Same like a long-term stock investor doesn’t care about the fluctuations within a day or a week, they care about the stock performance over a quarter or a year. The team should care about reducing variability in its capabilities eg. have a lower variability in Velocity, so more aggressive mezzo/macro commitments can be taken on while still allowing safe and sustainable delivery.

How can other teams count on us if we don’t have a clear commitment for the sprint content?

What if we are in an environment where other teams in the group/portfolio count on deliveries from us on a sprint by sprint basis? If we don’t have any commitment how will they know when to expect the delivery from us? If they intend to work in parallel to us, how will they know whether to plan for this or not?

There are a couple of ways to look at this. If 80% of the work is consumed by other teams then we should probably consider the organizational design. Maybe it would be better to work as a single team. Maybe it is a case of us providing a service that is consumed by many other teams, and then it might be better to move towards a pull system – where there is less reliance on dates and rather an agreement on priority, an understanding of the capability in the form of typical lead time from requesting a service from us to the time we deliver it, and then the consumers using that service whenever it is ready, either at their next sprint, or even better as soon as its ready. If you’re thinking this will make planning sprints more complicated and prone to changes you are right. The solution can be to move to full pull mode at the team level, or reduce the batch size you plan for, meaning shorten the sprint length.

If it’s just sporadic work that others depend on, make sure that is what you start with and make a commitment to deliver it. I wouldn’t be surprised if the term Class of Service comes to mind at this point…

What will be the engine of continuous improvement if we don’t have a target commitment to strive for?

Scrum is about Continuous Improvement, right? What drives this? Isn’t it the need to meet commitments? to be better about commitments?

Well, not exactly. The thing that is driving Continuous Improvement is the fact that there is a container, composed of a certain scope to focus on, a certain time to do it in, and the people/capacity to do it with. Think of circling the team with a rope telling them now move together towards the target. This will cause a lot of pain. Some people are faster, others are slowing the team down. Some impediments come up and cause problems. But the rope keeping the team together is forcing them to deal with the problems rather than defer them by making progress on things outside the container just to maintain the comfortable feeling of progress.

So in order to maintain this improvement-inducing container we need the time, the team, and a certain scope to focus on. We can do that with the Sprint Forecast mentioned before.

One important concept in Continuous Improvement is to have a vision / target condition to strive for. What is that target condition in a Scrum environment? As mentioned above, this typically is to improve capabilities.

Improving throughput/velocity requires more scope in each container.

How do we translate improving business agility to the container? The ability to define a shorter time frame that the team can still deliver in. The shorter the time frame the more opportunities to change direction without causing waste. Problem is that there is a limit to this. Work takes time, and there’s a limit to how small we can slice it to still be able to use a container of this structure. That is why, at some level, in order to improve business agility even further, we need to move to another form of container, one which limits the amount of things we are working on as a team at each point in time.

(Clarifying note – If you’re reading this to mean get to a certain level with Scrum then move to Kanban, that’s not what I mean. You indeed will benefit from Kanban at this level, but you can start your journey with Kanban in the first place, or move to it regardless of where you are on the way)

So can we get rid of the Sprint Commitment or not?

Well, my personal opinion is that we can live without a Sprint Commitment as currently practiced by the majority of Scrum Teams out there. It seems the creators of Scrum think along similar lines, as they replaced Sprint Commitment with Sprint Forecast in the latest Scrum Guide

I personally think commitment is important, it’s only a question what you commit to. I prefer to focus on the following types of commitments:

  • Commit to learn about your capabilities, care about them and continuously improve them, by using a focusing mechanism challenging the team as a whole.
  • Commit to deliver the class of service that the business and other teams expect, which means delivering on time when it matters, delivering the most throughput when it matters more, etc.


Some more ideas to try at home…

Before we conclude this long post – Some related experiments you might want to try at home…

  • If you feel you are over stretching, For a few sprints try setting a very low forecast and meeting it and see how it looks like. Talk about it. Learn from it.
  • Try limiting the amount of Features/Goals in one sprint. Talk about what it changes in the energies and focus of the team. If you cannot set a limit, that’s an interesting discussion in and of its own, that you should have.
  • Use the Sprint Goal and Sprint Stretch more aggressively. Set a lower goal, and commit to deliver the goal first, and as much of the stretch as possible. Goal should be something you can consistently deliver 95% of the time. (Mike Cohn recommends basing that goal on the mean of the 3 worst sprints out of last 8, another way is to use 2 standard deviations below the mean if you want to take a more statistics oriented approach). whether 95%, 85% or lower is your call. But the expectation should be that if there is a difficulty meeting even this commitment, it’s not forbidden to pick up the pace a bit in order to meet a commitment. Learn from it at the end of the sprint and plan more effectively next time.
  • Read about the XP Planning Game and try it… Seems the idea that iterations can be effective without a commitment is not a new one 🙂

Extra Reading


Scrum has some good things going for it. The Scrum-style Planning Game and Sprint Commitment as currently understood and practiced by most teams and organizations is not one of them. I hope this post will help at least some of those improve their results as well as their happiness.

How I would simulate time-boxed agile in the @getkanban kanban board game

Estimated Reading Time: 7 minutes

At Agilesparks we’ve recently been using the Kanban Board Game developed by Russell Heally (@getkanban) quite extensively. We use it as part of Kanban courses, sessions for Scrum teams that want to learn about Kanban, Kanban teams that are already working and want to raise their game, as well as in Kaizen sessions for project management teams.

We love what the game does, and it has actually become a challenge to coordinate which of us has the game kits at any point in time, especially because in large events we need 4 kits so we need to borrow from one of our nice clients that has 2 kits as well…

One idea we’ve been toying with for some time, is that it would be great to use something like this game to accelerate learning of Scrum as well. At a minimum, one of the questions I’m adding to the debrief for Scrum teams, is how would Scrum look like in this game, and what would be the effects. It seems clear to teams that Scrum would reduce throughput due to the need to clean the board every sprint, which means less ability to take advantage of the speciality of the Analysts/Developers/Testers. It would also make the game run slower due to the overhead of planning…

I’ve been reading some ideas from David Anderson and Russell about this, which helped me along. I’ll provide my take on this, but first a brief overview of the game to those not familiar with it.

The game simulates a process workflow where there is a stack (backlog) of cards which represent stories for development. The cards are pulled into a READY area, then pulled into Analysis, Development, Testing and finally deployed. There are different types of cards representing different work types/classes of service – a normal business value card, a fixed date card, a quality card, and an expedite card. Each card specifies the amount of work required to process it in each station, which provides the variability between work items so typical of product development and other knowledge creation areas. Another form of variability is the fact that how much work you are able to do each day is decided by throwing dice. You have dice in different colors that represent specialists in each area (Analysts, Developers, Testers), and you as the team playing the board can decide where to use each dice each day. Either use it in the specialty area of that person and gain a multiplier, or use it elsewhere without a multiplier. The game is played in cycles of days – each day you decide your strategy, throw the dice, play the game, update visibility charts, and also handle an event that might throw you some additional curve balls… That should suffice as a quick intro to understand the rest of the post, or at least as a teaser to find the opportunity to play the game. It really is highly recommended to anyone interested in Agile / Kanban / Scrum / Games. Exceptional work by Russell.

If you noticed so far, the game indeed simulates kanban. No time-boxes or batches, just flow and flow and flow. The only area where you get some sort of sprint behaviour is towards the end of the game. If you are approaching the end of the game and the teams know its coming, they will start to prefer cleaning the board and deploying items, rather than maintaining flow. That makes sense. If you announce end of the game on day 24 for example, but finish it a few days early without telling the teams, you will get flow behavior all the way to the end. You can play with that, depending what you want the teams to experience, and whether you want to have the timebox behavior as a pattern to discuss in the debriefing.

In general, it shouldn’t be too hard to make the adaptation of the whole game to timeboxes/sprints. maybe the biggest challenge is to have teams see the name Kanban on their new shiny Scrum process training 😉

But seriously, the main thing you need to take care of is the sprints. The concept of 3 day billing cycles in the game can be extended to portray a sprint. You would start the cycle with planning what cards you will work on in the cycle. This requires looking at your velocity in the last cycle, your capacity (cubes and statistics…) thinking about changes that were made in the environment (Carlos etc.), and the cards that are currently in the backlog. You would commit to what cards you plan to deliver.

Which gets us to the backlog… The trivial option is to make the READY area the backlog, and only pull into the READY area (into the board actually) cards that fit into the planning. This is not perfect though. For starters, how do we model the work that is done by the Product Owner? In addition, the whole flow from READY through analysis, development, testing might be a bit too long for a 3 day cycle.

That brings me to an alternative I’ve been thinking about – make the Analysis phase the work of a “Product Owner”. Use the analyst dice to represent the Product Owner, and the “Analysis Done” area the “Sprint Ready” backlog the teams can use for their planning.
This has the benefit of portraying the Product Owner work, it reduces the cycle time within a sprint which I think will provide a more reasonable simulation within a 3 days cycle, and can also bring about a discussion of the wastes of too much sprint ready backlog, versus a team that runs dry during a sprint. (Which is one of the common problems with Scrum teams, and a big benefit of doing this game with them I think)

So assuming the Analysis Done was the sprint candidate/ready backlog, the team does planning, pulls the planned stories into another queue between Analysis Done and Development in progress, which we can call – the Sprint Backlog

A sprint will be 3 days where the team works to finish and deploy all the cards in the Sprint Backlog – processing them through Development and Testing. Within this sprint the team also needs to take care to replenish the “Sprint Candidate/Ready Backlog”, because remember at the end of the cycle, there is another Sprint Planning, where they will need to have enough candidate cards that they can pull into the Sprint Backlog, to avoid starvation in the sprint. To properly simulate a real Scrum environment, it shouldn’t be allowed to pull cards within a sprint, because it is harder to plan within a sprint.

For advanced uses and for those Scrum people which are crying this is not fair, we can discuss a couple of options. One option is to allow pulling stories, while paying a fine for it to represent the cost of replanning. For example, you can put one of the dice on planning a story instead of executing it. Another option is to allow pulling quality cards during a sprint.

In general btw, we need to think how to portray the cost of planning. In a typical stable Scrum team, there is a cost of about 2-3 hours of planning per a 10 day sprint. This is about 4% which should be negligible in the game. Another option is to just compare the time it takes to do rounds of flow versus timeboxed rounds in the game and see what is the actual time it takes to run the game… I would expect flow to run much faster than the time-boxed version… but need to try it!

At the end of a sprint, what would happen is that you expect to have clean Sprint Backlog, Development and Testing stations, with all the cards deployed already. Any work that is not completed will probably be continued into the next timebox and should be included in the plans. I’m thinking a fine should be included here – every card that spills to another timebox should have a few points of work added to it (e.g. if there are 12 development points, the team finishes with 6 points of work left, in the new timebox there will be 6+3 points of work)

What would happen to Cycle Times? I’m quite sure cycle times will be much higher for a team doing timeboxes. The need to keep a queue of work ready for sprints will probably add about 2-4 days of cycle time, depending on how the team balances safety of having spare stories, versus the waste of having a story decay in the queue. Since the game doesn’t model a price for decaying stories, I assume teams will prefer more in the queue. The only thing that will stop them from doing that is limited amount of analysts… need to try it but I’m guessing there is a chance that the analyst will not be able to keep up, or at least we need to create scenarios that impede him from keeping up (e.g. blockers in analysis, reduced capacity of analysts, or taking stories that were analysed and cancelling them so now analysts have to rush to replenish the ready stories queue)

The event cards are another area which might need tweaking. For one, some events are unfair to introduce in the middle of a timebox because the team should know about them when planning. Need to look at them and align them with the timeboxes as necessary. Beyond that, some new kinds of events can be leveraged to spice up the timeboxes game (see above for example)

Will the effect of time-boxes be realistic enough? The concern is that if the time-box is too short, it will be hard to deliver stories and run an effective time-box. Similar to what teams experience when the story size is too large for the sprint. Basically, need to play around with it and see… I think that by removing the Analysis from the sprint itself I reduce the chance of this happening, but maybe its not enough. Worst case can play with multipliers on the cubes some to make the team capacity higher compared to the work, or strengthen the effect of the quality cards…

The WIP limits go away in this variant I think. The WIP limit is the Sprint Backlog which is time-based, not station based. An advanced team can decide to use WIP limits on the stations to work more effectively, or we can re-introduce the WIP limits as an event card during the game. While on this matter, a question I usually ask teams in debriefing is what would happen if there wasn’t a WIP limit. The answer I hear is that they would probably start more work than they can finish, and throughput and earnings will go down. QED 🙂

I think this is enough for one post. Should give you ideas how to play with the Kanban game in a time-boxed manner. There are probably other aspects that need to be taken care of, but lets be agile about it folks…

I’m hoping to try this on my own, probably with the AgileSparks team, sometime soon, and report. In the meantime, any comments or ideas are welcome.

And again, thanks Russell for the great game, which probably deserves to be a platform, with endless options of what to do with it. If we could have this as a Lego kit that we can play around with, it would be amazing.