Tracking Organization in Scrum Teams

How Do We Track Organization Visually?

29 April 2014


There is a difficulty tracking many Scrum teams in any typical organization. Although each Scrum team has its own work area with boards and charts, it is easier for managers to look at all teams and sprints in one place. In this article I will explain how we modeled and created a board that showed all Scrum teams and their work in one simple place, and how this visualization uncovered problems and bottlenecks.

At first, we regrouped the organization software employees as cross-functional Scrum teams based on the current skills and experiences of individual team members. We ended up with five Scrum teams, each working on multiple products. Actually, the products are based on the same technologies and/or business domain. The team focus is on the release level, using a round-robin basis. Typically, they work in Release 1 in Product 1, then switch to Release 1 in Product 2, then switch back to work on a Release 2 in Product 1, and so on.

After this organizational restructure, the manager held a meeting with all team members and got feedback and adjusted the organization of the teams.

Modeling: The sticky notes

We create one sticky note for each sprint, regardless of its status (whether it is in progress, waiting, or finished).

Sprint sticky note template

The sticky note includes product code, release number, sprint number, and finish date. Planned points are written on the top left side, velocity at the lower-left side, planned effort on the top-right corner, and, finally, burned effort on the bottom-right corner. Management required plotting burned effort to track team effort and commitment in the sprint.

The other sticky note is used to show product backlog readiness. It shows that we have clear vision, needs, and an amount of work that enables us to start release planning and sprint work. The number of backlog items is used as an indicator of the amount of ready work.

Ready sticky note

Modeling: The board

First we prepared a metal board, notecards, pens, and magnetic pins. We divided the board into columns that represent the states as follows:

Scrum teams' board

  • Team Name and Members column: Shows each Scrum team name and its members. (Team names are written in Arabic!)
  • Products column: Lists all products that the team could possibly work on. This is mostly based on past experiences of the individual team members.
  • Not Ready column: For each unready product backlog, a sticky note with product name is posted. A not-ready sticky note is used to note whether there is no backlog, the backlog exists with too few items, or the items are vague or incomplete. Usually the product owner (PO) can easily judge the backlog item's readiness for release planning.
  • Sprints Ready column: Includes ready sprints in the current release.
  • Sprint in Progress column: Shows the current sprint in progress. Be sure that only one sprint exists in this column per Scrum team.
  • Done column: Shows recently completed sprints that are not deployed yet.
  • Deployed column: Shows sprints (actually, a group of sprints that constitute a release) deployed to the production environment.

Explicit readiness definition

For explicit visibility, the conditions of readiness are written in blue at the bottom of the chart.

Discoveries

  • After modeling, management observed that there were two teams that had no ready backlogs. Management directed product owners to fill the gaps. We agreed to keep two sprints in the queue to ensure that the teams were not losing time waiting between sprints.
  • We observed that one of the releases was stuck in the Ready column and not deployed in the production environment.

Conclusion

  • Visualization is important for management to keep a bird's-eye view of all Scrum teams' work.
  • Management can see the sprints flow and can focus to resolve any impediments or bottlenecks.
  • All Scrum teams get a positive feeling as they can see their work in the context of the entire organization's work.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Tim Baffa, CSM, 4/29/2014 2:51:36 PM
I concur with your 3 conclusion points. I have a couple comments/questions:

1) Not sure what value can be placed in the lower left corner of the Sprint Sticky Note (velocity). Velocity is a measurement for an entire sprint, and should not be used as any type of metric at the item level.

2) Velocity is completely subjective to the estimating of each specific team. Since your "Discoveries" section states that management learned early oin that two teams did not have any stories that satisfied a definition of ready, I can assume that multiple backlogs supported these 5 scrum teams, and that the estimation process was again completely subjective (by team). Keep in mind that velocity should never be used as a cross-team metric of performance.

3) While transitioning to Agile is difficult for most organizations, as Scrum Masters we should discourage any type of behavior where management uses scrum metrics (burn-down, etc) to track team "commitment". A primary value of Scrum is centered around the idea of Theory Y behavior, in that given the proper conditions, employees desire to excel at their work and are responsible assets. Measuring in-sprint performance of any sort encourages Theory X behavior, centered around mistrust and the need for micro-management. Keep in mind that any "commitment" for a sprint is made by the team to each other, to perform to the best of their abilities to achieve the sprint goals. The sprint goals are only an estimate provided to management of what the team believes is possible for that sprint, never a commitment. That is an artifact of the contract game.
Ahmed Hammad, CSP,CSM, 4/29/2014 3:22:34 PM
Thank you for your feedback

1) I meant that, the single stick note item represents a whole sprint, this is why we put velocity on it. So a single item is actually a whole sprint. I am afraid I confused you in the article.

2) I totally agree with you. Really the velocity is not compared across teams, it may be an indicator for the same team across multiple sprints of the same product. The manager is aware of the velocity metric context and it is not used for any team comparison or even team evaluation.

3) I meant by commitment just time commitment factor, as some of the team members are shared. Actually it is the commitment of management to let the team focus on the sprint as planned and to commit to not switch them to other projects or tasks.

You must Login or Signup to comment.