Monthly Archives: November 2010

So, What’s the Point?

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.

*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.

Is Entrepreneurship Genetic?

Genetics Portal Logo

Image via Wikipedia

I just finished attending the last session in a great series about entrepreneurship that was offered by Indiana University South Bend. While I was filling out an evaluation form for the series, a student happened to sit down next to me to fill out his survey. I was surprised when the young man offered his feelings, those of disappointment, that the series was filled with people whose families had owned businesses. In addition to that, he continued, Michael Kubacki,  President and CEO of Lake City Bank and former member of the Federal Reserve Bank of Chicago,  upset this person so much that he had to leave the room. To say I was dumbfounded is an understatement. I was so impressed with the speakers and their accomplishments that it was beyond comprehension that somebody would have such a diametrically opposed view. I responded with mere grunts. It was one of those moments that I wish I could back. It seems like a missed opportunity to perhaps share a different perspective.

Indeed, the Entrepreneur Lecture Series 2010 did contain a number of speakers that had family businesses or were children of business owners:

  • Mark Tarner, President of the South Bend Chocolate Company – his father was a chocolate maker
  • Amish Shah, President of Kem Krest – his father owns a successful business
  • Rob Bartels, Jr., President & CEO of Martin’s Super Markets, Inc – Martin’s was founded by a family member
  • Larry Davis , President of Daman Products – Daman Products was started by his father and he

I believe that there is most likely an advantage to being in a family that owns a business. As the son of a minister and a secretary, I can only imagine that being around people who own businesses exposes you to an abundance of knowledge about how businesses actually work (marketing, planning, product management, finance, etc..) that are not quite as accessible to other people. It is important to remember that just because some people may have an apparent advantage does not mean that the goal is out of reach for you.

This year’s lecture series kicked off with an inspirational lecture titled “Seize the Opportunity” from the South Bend Chocolate Company’s President Mark Tarner. Mark reminded the attendees that the United States is still “the land of opportunity.” Mark is an extremely hard worker, constantly investing time in the company. Mark emphasized planning as one aspect of seizing the opportunity, but ultimately you need to take action on your plan. Apparently, the gentleman next to me this evening missed that part.

Amish shared the impact of the economic downturn on his company and how Kem Krest has had to adjust.

Rob shared that Martin and his wife, the supermarket’s founders, subsisted on the ‘shrink’ of the store. The ‘shrink’ is the food that is not good enough to sell any more, but is still good. Think brown banana…

Larry Davis shared his experience about the hard times starting his business. It was about a decade before their business was really thriving.

Each of these people, and most of the other presenters, had to overcome adversity before they became successful. There was a common theme, as well, that just because you were once successful does not mean that you now sit back and rest.

In 2009, I went to Chicago to hear Molly Fletcher, agent to Tom Izzo, top female sports agent, and author of the book “Your Dream Job Game Plan, 5 tools for becoming your own career agent”, speak to a group of Michigan State University, Northwestern University, and Ohio State University alumni. Molly shared some keys to what she called “your dream job game plan.” I believe the advise is equally applicable to entrepreneurs:

Have passion and style
Be fearless
Have a game plan
Execute flawlessly
Manage your choices

Lastly, and probably most importantly, Molly suggests surrounding yourself with other “five tool players”, those who are going to help you become better. I believe that this  last point would be particularly valuable for this man that spoke to me this evening. Being  jealous of the presenters is not going to move you forward. If you want to be like those people, reach out to them. Build a relationship, and try to learn from them. The speakers are entrepreneurial, and not only have been successful in business themselves, but are excited by the prospect of others pursuing their business dreams as well.

Would I have changed this man’s mind? I don’t know. I do hope that he realizes that what the future holds for him is largely within his control. Jealousy or disappointment over another person’s perceived advantage will only distract him from doing great things himself, as it will with any of us.

Entrepreneurism isn’t a matter of genetics, it’s about being fearless, having a plan, and executing.

Lastly, thank you IUSB for hosting the series and opening it up to the public free of charge. I look forward to next year’s series.

Michiana Agile Practitioners – December Meeting

I just posted a new notice for the Michiana Agile Practitioners gathering at Hacienda (4650 Miami St, South Bend). The meeting will be on December 6th at 5:30 PM, and we are typically done by 6:30 or 7:00. We meet in the patio area, which is closed in and comfortable, even in December. Topics for discussion range from process to engineering practices, and are not limited to one particularly technology stack or another. It’s more of a community than a “meeting, ” so please join and don’t feel any pressure. There is a posting on LinkedIn, so feel free to join the group and participate in the discussion.