Is this a bug or a requirements change?

In my day job, I work as a software architect and scrum master for a large corporation. Today, a group of managers asked me this question. I say what’s the difference?  In Scrum we try to focus on business value.    Let’s say there are two potential changes on the table:

1. A bug the delivery team introduced with this release. An additional character is displaying in a drop down box text value. All users will see the bug.

2. A new feature/requirements change that we learned from the first people to actually use the latest release in production. Making this change will reduce the potential for error and save each user some time.

All of our users work for the company, so ‘soft’ benefits like avoiding embarrassment caused by #1 don’t matter a whole lot. We don’t have time to do both. In this hypothetical scenario, the effort to fix them is identical.

The waterfall organization, focusing on the ‘contract’ between development, PMO, and the customer, would tend to fix #1, as #2 is out of scope.

The Scrum team would ask which item delivers the most business value. Business value can be tough to determine in a large company. When the user group numbers in the thousands, saving each user some time, even if only 5 seconds/day would be a flag to me, though. Even at 1000 users, 5000 seconds/day x 200 work days/year = 278 hours/year in potential savings. While that’s not going to make or break a large company, it’s clearly more value than the 0 seconds/day the bug fix would save users.

One thing I like about Scrum is the fact that it exposes everyone on the delivery team to patterns of thinking that in many large waterfall organizations are only known to senior managers. Scrum is helping our team members behave like business people, which is something sorely needed in a Dilbertian world.

Leave a Reply

Your email address will not be published. Required fields are marked *