Tag: Kanban

Posted on

A wee bit of predictability math

Agile teams who start their Agile journey in Scrum quickly learn something called story pointing, and how to use it to enhance their predictability. (Hopefully they also learn to avoid trying to leverage story pointing to understand productivity, but that’s a separate story.) Anyway, there are many internet references to story pointing. Pointing is a clever way to avoid the need to make all the stories in our backlog roughly the same size prior to implementation.

When the team is also developing on a static cadence, say a “sprint” length of two weeks, then we can call out a set of stories, put them “in” our sprint backlog to be done in this sprint, add together their story points, and call that our forecast, say 40 points. It used to be called commitment and I still think that’s a good name: we commit to the Business that we’ll do everything we can to make our forecast. We can do that because we’ve established historical perspective that tells us we are consistently able to complete that many story points in every sprint. Jira (among many tools) shows us this in the Velocity Chart report.

Velocity, then, is about a forecast over a static time period. However Kanban teams are among those who don’t “sprint”; they don’t develop on cadence. They do demonstration and review on demand, and to establish predictable behavior they consider flow instead of velocity. They have more work to do on their stories: instead of pointing them, a Kanban team needs to split their stories until all the stories they develop and deliver are about the same size. When that is true and if we are on a cadence, we could switch our units of velocity from story points per sprint to stories per sprint and it wouldn’t matter much. When we are not on a cadence as on a Kanban team, we think about flow instead, or the average time to complete a story once it is selected for development; this is called Cycle time. (Separately we can have a discussion about the related measure, Lead time.) Note that Cycle time and Velocity are inversely proportional to each other if both are being measured with the same units (either stories, or story points). Example using stories:

Let Velocity be the average stories per sprint
Let Flow be average days to complete a story
then Velocity = L / Flow
where L = sprint length in days

If we are using story points rather than stories, and not trying to get all our stories to be about the same size, Jira only helps us if we are on cadence, ie sprinting. Jira does not measure cycle time for story points, only for stories, so a story point-based cycle time must be calculated manually. That being the case, we discourage story pointing unless our squad is sprinting. Instead we encourage splitting our stories until all the stories we select for development are of similar size.

Cadence, such as the sprints in Scrum, is very useful. Teams typically thrive on the rhythm and story pointing is not difficult (at least, not once you “get it” – yet another separate story!). Kanban teams have more flexibility but as is so often the case, it’s a trade off: more discipline in story splitting is needed to be successful.

Posted on

to Kanban from Scrum

I recently transitioned a team from Scrum to Kanban. Here are some of the things I learned. Those of you experienced in Kanban – I’m really not – will probably find this boring. Many of these items are bread-and-butter for Kanban.

  • Kanban has less formality but requires the same degree of rigor as Scrum or even more. This implies a greater requirement in Kanban for discipline, enough so that teams can do it, but are unlikely to do it well, without focused help from a good coach, unless the Kanban Master is quite well-trained. That is, Kanban Master(s) needs to be higher quality with respect to Agile and Kanban techniques than are most Scrum Masters with Scrum techniques, for the team to be successful.
  • Kanban is Lean. Start with what you have, keep learning, and feel very free to change and expand your board. More columns, maybe more rows, and make it truly live and visually representative of your current work, state and needs. Be incremental. Experiment, try stuff, continuously improve. Focus on pull in lieu of push. (A good and easy example of pull is inserting a new column in a Kanban board between In Progress and Testing called Ready to Test.) Oh, and read Kanban by David J. Anderson. Don’t argue, just go read it. I found it a challenge to find the board online that I wanted to cite as a good example. Here’s one that is not bad, take awhile to just study it and think about what they must be doing and how it visualizes things for the team.
  • Policies. Each column-to-column move made by a work item is a state transition; endow each state transition with a policy. In Scrum, from In Progress or Doing or Testing or whatever to the Donecolumn (state) has a policy associated with it called Definition of Done. Optionally, from Backlog to In Progress has a policy associated with it called Definition of Ready. Each policy specifies the conditions that must be true to allow the state transition, as well as the actions to be taken when the transition is performed. In Kanban, all possible state transitions should be endowed with such a policy. They don’t need to be lengthy, but they definitely should be visible and easily found so that they are quickly referred to during work and updated during retrospectives with new knowledge gained.
  • WIP. Going from Scrum to Kanban made the transition from (work in progress naturally limited by 2 week sprints) to (WIP limited poorly and without a strategy) painfully easy to see. Shoring up the WIP limits to enable good flow and predictability became priority almost immediately. Fortunately it’s not difficult as long as the principles are understood. The rule of half got us in the ballpark: Team: “is this about right?” Coach: “try half that”.
  • Reviews. In Scrum there is a sprint review every two weeks. Everything forecasted for a sprint is reviewed or thrown back into the backlog if not done. In Kanban there is no such formalism, but every work item should still result in a product improvement that is executable, demonstrable, and demonstrated to a product owner or stakeholder(s) and approved. Visibility is key, so put the appropriate state transition into your Kanban so that you can know that all your work items pass this “it’s done, and it’s approved” policy test. In addition, don’t underestimate the value of cadence; maybe you should keep reviews of your working stuff on a regular cadence. Kanban doesn’t care; if it adds value, do it. Does that make it Scrumban instead of Kanban? Not sure, and not sure it matters, but rhythm is often useful to a team.
  • Retros. In Scrum there is a retrospective every two weeks. One must account for this functionally. In Kanban, once again, the retro does not have to occur on cadence, but experience shows it has to occur with similar frequency in order for your team to qualify as a team seriously engaged in continuous improvement. My suggestion: stick with what you did in Scrum, if you can. Set up a convenient time, and do your retrospective every two weeks on cadence. If this is the only thing you do on cadence, I believe it’s the best thing to do on cadence. Retros are the most important event, right? Rhythm is useful to many teams (see previous bullet), and it is a reason Scrum is so easy to like.
  • Kanban doesn’t have a Product Owner. I recommend a Product Owner anyway. Bring someone in from the Business who will do the things a Product Owner does. Make that person a full-time member of your team.
  • Kanban doesn’t have a Scrum Master. I don’t recommend one, but I almost do. You need a level of effort of approximately a one full-time person to engage the team in continuous process improvement, remove impediments, and facilitate ceremonies/events of importance. In fact, maybe the LOE is higher, because Scrum’s processes are straightforward whereas Kanban is nominally very flexible and dynamic. My suggestion then (falling just short of a recommendation), is to avoid underestimating the value of a single, dedicated person who acts for your Kanban process as your Scrum Master would if you were using Scrum. Call him/her your Kanban Master perhaps, if you as a team decide to leverage this idea. Be sure that person reads Kanban.
  • Story pointing or story sizing. Predictability is a major element of growing maturity as a team. In Scrum, we often perform Story Pointing as a part of backlog refinement, to understand the relative size of each work item (many of which are user stories, hence the name). However, in Kanban, one doesn’t measure velocity because there are no sprints. Instead one measures lead time and cycle time. For this to work well, each work item needs to be “about the same size” as its brethren. Story sizing keeps this from being a need, but story sizing only works if you’re on a static cadence like two weeks. If you have some 1s, 2s and 3s floating around, you’ll probably be ok with the assumption that all stories are close enough to the same size to ignore their differences. If you have some 2s, some 3s, but a 13 or three as well, then the assumptions of similar size required by the lead time and cycle time measurements don’t work as well, and those measures won’t help you nearly as much to understand your predictability. Therefore, a significant element of improving maturity with Kanban is to solve this problem by splitting those 13 point user story into stories that are 1, 2 or 3 or so in size, that is, all of similar size. And we don’t do this by explicitly sizing the stories, we just split them until the collection of stories all are “about the right size”.
  • Story Understanding. On the other hand, part of backlog refinement is ensuring that the whole team understands the needs represented in the backlog. My experience is that this happens very naturally when stories are routinely sized. If the team stops sizing stories, they often forego exactly what it takes for them to have an adequate understanding of the stories. Quality suffers. Thus, even if the team is not sizing stories any longer, they still need to understand them as well as when the stories were being sized. The team must figure out how to maintain that sufficient level of understanding of the backlog.

Hope that helps! Keep learning and improving.