Category Archives: Tracking

There can be only one

Leave a reply

Are you on a team where tasks seem to get started but not finished? Does the daily standup involve updates where individuals work on what seems like the same handful of tasks for multiple days?

Here’s a technique you can try for limiting work-in-progress. Instead of identifying task ownership whereby team members write their name on multiple task cards, ask each to use a single PostIt note with their name on it. Each person gets only one note with his or her name on it. Let’s face it, even if you have more than one task in the “In Progress” column, you can only work on one at a time. The sticky note is to be placed on the task that is being worked on at that moment. The note is moved throughout the day when changing tasks.

Here are some benefits of this approach:

Token to help address too much WIP

  1. Only one task can be claimed by any individual.
  2. The team now sees exactly who is doing what work at any moment.
  3. The team sees which tasks that are “In Progress” but not being worked on.
  4. Knowing what each person is working on makes it safer for team members to begin work on idle tasks.
  5. By no longer staking your claim to a whole set of tasks, you invite more collective ownership of completing the team’s work.

In addition to simply putting your name on a single sticky note, you could also capture data about context switching with this simple method. Write the date on your token. For that day, put a tally mark on the note each time the token moves from one task to another.

By using the date and tally marks on the card, you can get a sense for how much context switching is happening throughout the day. Perhaps thrashing is an impediment for your team. Of course, if you switch tasks six times and 5 tasks are completed, you probably don’t have a problem. If you switch six times and nothing gets to “Done,” there may be an impediment’s root cause to search for. Collect the notes throughout the iteration and look for trends in the data.

I hope you find this technique useful. Feel free to comment on the post.

So, What’s the Point?

9 Replies

One of my teams been involved in a bit of a discussion as to whether or not defects in the product backlog should be sized using Story Points, just as we size stories. Mike Cohn has a very good blog about “Story Points for Bug Fixing.” As I read his post, I believe it is specific to the scenario where a team has inherited a set of defects from a prior release or a legacy product that they are going to attempt to work through in the midst of delivering new features. Mike’s recommendation is that defects be sized, much like stories would, and that the resulting completed work would count toward the team’s velocity. I agree with that approach. I believe the scenario that we’ve encountered is a different one, and thus a different approach may be more suitable. The scenario I would like to explore is one in which defects found in the current release’s earlier iterations. Should those defects be sized and be included in the team’s velocity?

Consider a scenario where the features set to be delivered consists of 100 points of work, and that the team’s average velocity is 20 point per iteration. The figure below shows what a release burndown might look like under these conditions. Prior to iteration 1, there are 100 points of work to do. At the end of iteration 1, we have completed 20 points of work with high quality and there are 80 points remaining. Finally, at the end of iteration 5 the backlog has been reduced to zero*.  The burndown in this scenario is “Backlog Points Remaining after Iteration – Scenario 1”

This burndown shows the points remaining after each iteration is complete. Each iteration, the team completes 20 points of work on stories that are in the backlog.

In another scenario, we identify defects from earlier iterations, size them, and include them in the iteration’s velocity. So, in scenario 2, each iteration still shows a velocity of 20, but the burndown does not reach zero after the five iterations are complete.

This burndown shows the points remaining after each iteration is complete. Again, the team completes 20 points of work each iteration.

Without the proper visibility to the information feeding this chart, it appears that the product manager is growing the backlog. However, if you were to decompose the velocity into its constituent points (illustrated below),  you see that in the second scenario the contribution of defects to the team’s velocity grows throughout the release cycle. The assumption that the effort put toward defects will grow is reasonable; if there are defects being introduced early on in the release and nothing changes to address the root cause, the defects will continue to be introduced and their contribution will become more and more significant. Without transparency to what made up the velocity, the team can feel that they have executed with their ‘expected velocity’ and the product owner can feel like she is getting asked to make unreasonable concessions due to quality problems. Do you think it is reasonable that the product owner would remove scope because the quality of earlier deliverables was not high?

This view shows the points that were dedicated to stories in the backlog compared to points assigned to defects.

So, what to do?

I do agree that bugs from prior releases should be sized by the team and prioritized by the product owner, much like a new story. In that case, defects from prior releases would be included in the velocity, and the product owner could determine what new features could be completed if work toward resolving legacy issues was suspended.

If defects introduced in earlier iterations are going to be fixed in subsequent iterations, their contribution to the team’s velocity should be made big and visible. Only if the information is visible will it get the proper attention so the team and product management can work to figure out the root cause of the defects. If the team is not going to make the effort put toward resolving defects visible, I would suggest that it would be best to not size the defects and to merely let the ongoing reduction in team velocity be the canary in the coal mine. Unlike the scenario that Mike spoke about, the team cannot reasonably suspend defect resolution to deliver additional features.

Lastly, if the team’s anticipated velocity includes an allocation to fixing defects that are yet to be introduced, this needs to be accounted for as part of release planning, as well.

Ultimately, it is critical to identify the root cause of the defects and to address the root cause. Without addressing the root cause, we are left with an ever-increasing allocation of time to resolving defects that we are introducing as we build new features.

Conclusion: Sizing defects that are introduced as part of the release that you are currently working on can produce a misleading velocity. If you do want to size defects and have them contribute toward the velocity, segregate the points from Defects and Stories so that the effort toward each becomes plainly visible.

Footnote:
*For the sake of illustration, I have simplified the scenario. Indeed, there is often some variability in velocity from one iteration to the next. This scenario also assumes that the product backlog is constant throughout the five iterations.