I recently had a discussion with a Product Owner working with one of my teams. He was frustrated because a new feature that was released last week has a bug and he doesn’t want to advertise the feature until the bug is resolved. This is an established team that works in 3 week sprints and is releasing code to production at the end of every sprint. This team is also working for a global insurance company where process and regulation are part of breathing and Scrum is just starting to be accepted as a formal methodology. That’s to say that releasing code to production every 3 weeks in this environment is pretty darn fast.
The Product Owner’s question was, “Can’t we move to 2 week sprints so we can get the work out faster?” (I should also note that the team has been largely together for a long time and the Product Owner is the newest member of the team.) His feeling was that if we had shorter sprints then he wouldn’t have to wait as long to get a bug resolved. He is not happy about having to wait another 3 weeks to promote the new feature. I am not happy about it either, but I don’t think the number of weeks in the sprint is to blame. The team has been established on a 3 week cycle for a long time and nothing significant has changed to warrant making a change this drastic.
I suggested that the process is not at fault here. The issue was actually with the quality of work being turned out by the team. Testing should have been more rigorous (including his own, btw) and that would have caught the issue before it was released. He wasn’t crazy about this explanation as it did nothing to get his feature out there sooner, but I held strong to the quality problem. I said I would talk to the Scrum Master about bringing this into the next retrospective so that team would be aware that defects are being noticed and having a real affect on the product and the reliability of the team. After all, if the quality of work was better, he wouldn’t have to wait even 2 more weeks for a properly working feature. He would have it right when he expected it.
And if we introduced a shorter sprint cycle velocity would surely suffer the pains of change.
Perhaps there are other issues we need to look at in this team as well. For example, maybe they are just committing to too many story points? I would always rather see a team reduce their velocity in order to improve quality than rush to get a lot done and risking defects. Perhaps there was a miscommunication in test cases and something needs to be looked at there? Never underestimate the value of good test cases. Whatever is causing the quality issue it is most important to identify the issue in the team even though it is easier to blame the process.
Agile IRL 