One of the clients I work with is a networking company. One of the teams I worked with had a difficult time establishing a consistent velocity. Forecasting when a release might be ready for system testing was difficult for this group. This holds back other groups who have to integrate with them at the system level.

Leaving Defects Unsized

The Product Backlog and historical velocity information showed me that the team was not sizing defects. When inquiring why that decision was put in to practice the answer indicated that story points were seen as a measure of value. After all, the team is only credited with the point value of a User Story when the Product Owner has accepted the work as done.

The group sees defects as having no value and show that the original story was not really completed. We discussed if User Stories can be in an accepted state when defects exist for them. We talked about how to apply a formula to recalculate velocity and accommodate for defects. It seemed to the team to be a lot of work with little reward.

When prompted, the team came to the conclusion that defects looked a lot like User Stories and that they could see the relative size of them in comparison to those stories. Someone noted that the expected/actual language of a defect matched up well to acceptance criteria.

We discussed what makes up the size of a story, like how complex it is, and how much uncertainty we have about it. User Story size seemed to us to be correlated to the amount of effort the team needed to invest to finish a story. I admitted to having thought about story points as a value metric and had changed my mind, I now thought that they related closer to the cost of an item.

The team talked about what they believed and concluded that it would be worthwhile to try estimating the size of defects and see what happened. They already met weekly to triage them. Defects were stack ranked with the rest of the Product Backlog. It seemed to the team that it would require minimal effort to size them as well.

The Effect of Sizing Defects

Velocity stabilized with the team keeping all the items including defects in the Product Backlog relatively sized. The total point increase of the Product Backlog confirmed what most people thought; the projected release date was further out than first promised.

The predictable velocity allowed this team to now reserve a certain amount of point capacity to invest in automation and other infrastructure. Preventing defects instead of merely fixing them reduced their cost of feature deployment. This could be seen by them in different ways, such as the reduction of defects backlogged and less time spent in triage.

Understanding velocity showed data to help the team decide if more features had to be cut to meet the date, if the date would have to move, or if more people needed to be hired. In the end the organization acted on all of these options.

Share

The organization followed a structured work breakdown approach with tasks functionally derived. People were willing to approach product definition in an Agile way and wanted to experiment with User Stories. We discussed the vertical nature of Stories and that teams were formed orthogonally, based on the architectural stack. A few people pointed out that teams were split by functional area.

The group understood that co-located and dedicated teams fit the Scrum model. Yet voices grew stronger that teams were not set up to autonomously deliver end-to-end features. We talked about the merits of the cross-functional team and folks insisted that the group could not afford another reorganization. One of the Vice Presidents had declared that no “dotted line” relationships could be formed to create virtual teams. She found that such an approach diluted the commitment of individuals and made the process opaque.

We got in too some passionate discussions over the once taboo subject. I continued on with Story writing. We later revisited the team structure with executives prior to release planning. The decision to not allow virtual teams stayed in place. Release planning was put on hold for about two months and then they asked me back to finish. The VP had relented, and kept her job.

When I got back, the business unit could work in a matrixed organizational structure. Virtual Scrum teams had been created without going through another Human Resources led reorganization. We were able to proceed with release planning. The teams were organized where they could implement the features independent from each other yet stay coordinated. This helped increase their production rate while increasing the quality of features as well.

Share

Of course, I didn’t always find myself in a better place. One result had us building a product that became attractive for an acquisition, while our related labor cost did not. Many of us lost our jobs to promote the sale. Another consequence of success was having a senior executive in our organization determine that formally sponsoring Agile was no longer needed. We were invited to look for work in other parts of the organization for awhile, or had to leave the company entirely.

Yet there are times when I did help make things better. The best improvements I’ve been a part of happened gradually, required patience, and added up over time. This helps remind me that I can improve my current situation. I need to help the team see the problem clearly and suggest ways to validate proposed solutions.

If we have a shared perspective of the current situation, then we can agree on how to make it better. We will need to check in frequently, and constantly re-validate the understanding and approach.

Acknowledgments

I would like to thank Erica Young, Ken Clyne, Ronica Roth, Ann Konkler, Bob Gower, Jeff Patton and Ben Carey for their comments, advice, and encouragement.

Share