Category Archives: Kanban
What is the one focal point that catches every team member’s attention at the same time every day? Of course it is their Scrum board. Some teams go through the motions and use their Scrum board because they are told to; for effective teams the board is a way to collaborate, manage work in process, keep track of impediments and know whether or not they are going to meet the sprint goal. Effective teams turn their board into a highly-visible collection of critical information about their effort. It becomes the heartbeat of the team and helps set the cadence for each sprint.
Their board might look something like this:
Sprint Dates and Goal – as a reminder of the goal and the timeline. Seeing the sprint dates can be helpful if users who will be testing attend the standups so that they understand the sprint timing.
Columns for each step in their development process – This can be as simple or as complex as the team wants – it usually evolves as the team learns and tweaks its process to ensure a smooth flow of stories. In the example above, the team experienced issues with too many stories waiting for user testing. They created a column to show which stories are ready for user testing to make it clear to users when something is ready for them to test. During standups, the Scrum Master points out any columns where an excessive number of stories are piling up. Even with Scrum, the team may set limits for how many stories may accumulate in each column before team members swarm to address a bottleneck.
Sprint Calendar – during sprint planning the team members estimate on which days of the sprint they think stories will be Done and also when they will likely reach any other significant milestones in the team’s process such as being ready for user testing. This is a way of performing a sanity check for the sprint plan. It is also a way for the team to gauge whether or not it is on track during the sprint. When user testing is part of the Definition of Done, it allows the users to plan when they will be performing this testing. Putting team members’ planned vacation days on this calendar avoids surprises in the middle of the sprint. It can also help to put key SME’s or users’ vacation days on the calendar if these could impact the sprint.
Impediments – unresolved impediments. Making these visible is a way to track them and may have the side benefit of prompting outside stakeholders who attend the standup or visit with the team to help the Scrum Master by finding other ways to resolve them.
Additional Stories – these are stories at the top of the Product Backlog that are ready to be brought into a sprint but that are not part of the current Sprint Backlog. These are posted on the board so that they are readily available in case the team reaches the sprint goal early and can complete some additional stories in this sprint. Note that these are not called “Stretch Goals”. That term can be perceived negatively by the team, almost as if they are not pushing hard enough in the first place to meet the sprint goal.
Release Burnup – the bigger picture of what the team is working towards. This help avoid the sense of being in an endless churn of sprints with no end in sight.
For teams using Kanban, many elements on this board still apply but may need slight modification. Note the use of colors throughout the board. It is amazing how teams will adopt color schemes or symbols that communicate the state of their work, highlight important events, serve as key reminders, etc. One type of information not included on the example above is an area for Technical Debt. Creating an open area on the board for this invites the team members to note it as soon as it becomes apparent to them. These notes can then be translated into backlog items during grooming. This encourages open discussion about technical debt and surfaces this information rather than just having it in the team members’ heads.
A note for teams that use online/electronic Scrum or Kanban boards: additional information such as the PTO calendar, Impediments and release burnup can be captured in story cards and placed in a column dedicated to that background information. The sprint calendar can be captured by putting Due Dates on each electronic story card. On a physical or electronic board, the story cards can contain as much information as the team finds helpful. Typically the story number, title, and number of story points are included.
- The Scrum or Kanban board can be used to communicate much more than just the status of the stories and tasks.
- The information on this board should reflect each team’s personality and process. It will evolve as the team learns.
- The Scrum Master can help the team during the standup by directing their attention to potential trouble spots on the board.
There are lots of reasons why it is good or bad to have a Scrum team handle both new development work as well as support work. When an organization determines that the best way is for support and new development to be done by the same team, careful planning and a little bit of discipline during sprint execution can help meet sprint goals and stay on top of issues reported by users.
During sprint planning, a certain percentage of the team’s time needs to be allocated to support. For an existing system, that percentage can be based on historical metrics from the time tracking system. Of course this requires that people’s time for support and new development be tracked under separate categories. Also, the support allocation may vary sprint by sprint if there are extraordinary events expected in a sprint (e.g. major new features released to production in the previous sprint).
Based on the percentage allocated to support and non-development work such as backlog grooming, company meetings, etc. the team’s capacity to work on user stories is reduced. A sample capacity calculation is show in the diagram below:
During sprint planning, user stories are pulled into the sprint plan, tasks are identified for each story, and task hours are estimated. When the team has reached its hours of capacity based on total task hours, the sprint plan is complete. There is no need to create placeholder tasks for support items unless that helps with time tracking (more on this later).
All concerned stakeholders (including the team!) need to be aware what percentage of the team’s time is going to be allocated to support work. This becomes more important if a team gets hit with a lot of support work and the sprint commitment is jeopardized. This also underscores of the importance of looking at the team’s velocity as an average across many sprints since it will fluctuate depending on support needs in a given sprint.
Ground rules must be established and agreed to by team members, product owners, and representatives of the end user community that determine what work is handled as support items to be worked on immediately or as new backlog items for future sprints. One model for this is:
For business stakeholders who previously worked in environments where the support team would jump on any support request as soon as they received it, the ‘4 hours or less’ rule is the most difficult one to get used to. In traditional project organizations with separate development and support teams, some stakeholders viewed support teams as a way of bypassing development teams that were mired in 6 or 12-month long development cycles. When the organization adopts agile and they see that their requests can be considered (of course factoring business value relative to other backlog items) within a few weeks, they are typically much more receptive to these types of guidelines.
Who works on support requests depends on the size and composition of the team. A couple of models are:
- Dedicate one person per sprint to be the primary support person. Other team members focus on sprint backlog items. This works well when the team has a good balance of knowledge and skills.
- Pick up support tickets as they come in. This can work well and fill in some of the time gaps or delays within a sprint. However, a high volume of tickets can make it hard for team members to get traction on sprint backlog items.
Just like it is important to provide high visibility for sprint backlog items and progress, it is just as important to make support work visible. A Kanban board, complete with Expedite lane for high-priority tickets, and sticky notes for each ticket are an effective tool that can help a team stay on top of support work.
Why use a Kanban board when your company already has perfectly good help ticket tracking software? I have found that the extra level of visibility of tickets on the board reminds everyone about outstanding support work rather than letting it fall into the background. This is especially important when the team is focused on user stories and meeting the sprint commitment. Timely resolution of support issues can impact customer satisfaction as much or more than new features so its warrants the same level of visibility as a Scrum taskboard.
It is also helpful to publish the actual percentage of time that the team is spending on support while the sprint is underway. Remember how we told everyone during sprint planning what the support allocation percentage was going to be for the sprint? This is where the team’s progress on sprint backlog items is weighed against the support commitment. With a higher than planned support load, the team may not be able to complete all of the sprint backlog items; with the lower than expected support load, the team should be able to take on more backlog items than planned.
- Adjust team capacity to reflect anticipate support load
- Establish ground rules for what is handled as a support item vs. a new backlog item
- Track and report support effort vs. planned effort so that impact on sprint commitment is understood