Agile / Anforderungsmanagement

User Stories: “Definition of Ready” Kanban Board

Having trouble staying agile in a “traditional” environment? Are dependencies on external resources or factors affecting your productivity? Then maybe you would find a “Definition of Ready” Kanban Board useful! This approach uses a Kanban board to investigate the maturity of user stories and any external dependencies they may have. Any dependencies must be resolved before accepting a story for the product backlog. This ensures that stories in the sprint aren’t blocked by external factors and the team get can on with delivering the committed sprint backlog.

Sketch172123535_kanbanboard_740x415

Introduction

Scrum has proved itself to be a very popular software development framework. At its core, it has cross-functional teams, which bring customer, developer and tester closer together. The interaction this creates results in products which are more tightly focussed on business value without sacrificing quality.

For greenfield projects or new products this can produce great results in a short space of time. However, Scrum doesn’t always take place in a greenfield vacuum. Particularly in established companies, Scrum will be running alongside more “traditional” methodologies. More often than not, there are often dependencies on external projects, infrastructure and resources. The Gartner Group calls this mix “Bimodal IT”, and in a study last year, detailed how properly managing this mix is essential to attaining a bimodal enterprise. (If you would like to know more about this approach, just visit our next „Expertenfrühstück„.)

These external dependencies can lead to the following problem: user stories get started, the initial tasks are done and then a task, which depends on external factors, is next up. Often the external dependency requires time to process and has low priority for that external entity. In the meantime, it blocks the story completely. Work can start on other stories, but in a worst-case scenario, the story cannot be finished by the end of the sprint. This can put a major dint in the velocity and reduce many of the benefits Scrum is supposed to deliver. It doesn’t make a product owner happy to see that their high priority stories are not being implemented!

So if you have dependencies on “slower” external factors, how do you stay agile? One possibility is to define Definition of Ready for a user story as having resolving any external dependencies the story has. A good way to ensure this is to employ a Kanban board, which can be used to take account of these external dependencies.

„Definition of Ready“ Kanban Board

One way to pre-empt these impediments and blockers is to tease out the dependencies in a user story before it is declared ready for the backlog – or more precisely the user story backlog. This is done by using a Kanban board to assess the readiness of stories in the product vision backlog before making them eligible for the user story backlog.

The term “user story” backlog seems to be a misnomer when we already have a product vision backlog. The difference is that the stories in the user story backlog have been checked for dependencies on external factors and have been given the all clear. These stories are ready to be implemented in a sprint without fear of them being blocked by external dependencies. The sprint backlog is pulled from this user story backlog, rather than the product vision backlog.

A version of the board is shown at the start of the article. It should be clear, that the board can be tailored to your own needs and that this is just one variation! For instance, if you are working on mobile applications and require user interface designs, then maybe a UI Design column makes sense.

Product Vision Backlog

The product vision backlog is not part of the Kanban board.

The product vision backlog is what would normally be considered to be the product backlog. As with most backlogs it contains user stories, features and epics, which have been prioritised by the product owner. However, just because a user story is in the product backlog, doesn’t mean that it’s ready for the scrum team to tackle. First of all the story needs to be checked for dependencies on external factors. Once these have been resolved, the story can be added to the user story backlog.

 

Input

The input column is the first column on a Kanban board. The stories, features or epics that make it into the input column are the ones the product owner considers to be most important. In effect, this is a “close-up” of the high-priority topics in the backlog (the tip of the iceberg!).

Refinement

What happens in this column depends on the quality of the story, feature or epic.

  • A well-written user story could pass straight through this stage.
  • A feature can be broken down into its constituent user stories. Quite often, the external dependencies for stories based on a feature are the same and all the stories can be handled simultaneously.
  • In the case of an epic, a few start-up stories, which cover the basic desired functionality would be extracted, and these would continue through the process. The epic itself, or a modified version of it, would be placed back in the product vision backlog.

This step can also be used to make sure that all aspects of a user story have been thought through. Sometimes, when a Product Owner also has other responsibilities, they don’t have time to consider all aspects of a story (error conditions, acceptance criteria, etc.). Then when it comes to an estimation meeting or sprint planning, there are long debates where the story is discussed and modified or sometimes discarded. Putting a story through the refinement stage encourages the Product Owner to invest more time in creating a mature user story.

Resolve Dependencies

This is where the dependencies on external factors are checked. This covers a variety of different issues:

  • Firewall changes
  • Permissions, usernames and passwords for external systems
  • Access to test data and systems
  • Legal issues related to content or user data
  • Cost issues relating to external content or requests
  • Available APIs to external systems
  • Modification of external system APIs

When all of these dependencies have been clarified, the story is ready to be estimated and added to the user story backlog.

Awaiting Estimation

This column shows the user stories that are waiting to be estimated (in effect it’s the done column for Resolve Dependencies). Whether it’s poker cards or magic estimation it’s up to you, but once they’ve been estimated, the stories can be added to the user story backlog. Of course, it’s possible that new dependencies are discovered during estimation, in which case the story should be returned to the Resolve Dependencies column.

User Story Backlog

This is the actual backlog from which the sprint backlog is drawn. If the board has been used correctly, there should be no external factors blocking any of these stories from being implemented.

 

Work in Progress Limits

WIP limits apply here as in any Kanban board. In particular, the input column and the Ready for Estimation columns require limits. Because several stories may have the same dependencies, the need to limit the Resolve Dependencies column isn’t as pressing. Stories, which have the same dependencies, can be grouped together.

Meetings

Meetings to handle the backlog refinement should occur regularly between the scrum master and the product owner. They may be informal due to co-location or fixed as needs be. In these meetings the current product vision backlog is reviewed, the stories are refined, and any non-technical dependencies are identified and owners assigned to clarify the dependencies.

A separate technical meeting is often required, where input is required to identify technical dependencies, as well as to estimate the refined user stories. These meetings usually happen once a week, and often require the whole scrum team (depending on the maturity of the team).

Resolving Dependencies

Depending on the type of dependency, they can be taken care of by the scrum master, product owner or one of the scrum team. Although this would appear to remove resources from the sprint, the velocity will capture this and it will settle down over time. Arguing that less gets done in the sprint is just short-termism, as the problems will appear later and create greater disruption than if they are dealt with early.

Implications for business value

External dependencies often mean that the absolute maximum business value cannot be delivered immediately. Unless you manage to change the external processes and dependencies, this won’t change. However, by using the Kanban board to manage the users stories, these dependencies can be identified early on and not just when the story is halfway through a sprint. Resolving the dependencies, while maximising the current sprint potential, ensures that work gets done efficiently and effectively.

Conclusion

Agile teams often find themselves dependent on external factors, which can play havoc with their productivity. The Definition of Ready Kanban board is a means of identifying and resolving these dependencies before they become blockers in the middle of a sprint. By combining agile and traditional environments, it provides a useful stepping stone on the path to the bimodal IT.

Passende Artikel

Kommentare gesperrt.