In Scrum, we depend on the team for estimation. It is the team that estimates the efforts and time for each product backlog item; it is the team that, in the sprint planning meeting, breaks down each item into tasks and estimates efforts for each; it is the team that, in the daily Scrum, estimates the remaining efforts. . . .
Hence, estimation accuracy depends on the team. Here I mean that it is not only about the team's competence, familiarity with the technology, and know-how but also about the team's morale and its motivation to take responsibility at full speed (or with enough speed).
Let's imagine this scenario: Scrum has been applied in an organization for more than one year, and most of its members are now familiar with the Scrum process. People are getting used to all those meetings, which once were fresh and new but now seem a bit boring. Furthermore, the team members know what the ScrumMaster and product owner care about most: All they really want is a smoothly finished sprint that doesn't slip and that creates the desired product increment.
What does "smooth" mean? It means that the remaining efforts are not too much greater or less than in the linear estimation setup in the sprint planning meeting. This is easy to achieve, since both that linear estimation and the remaining efforts (in each daily Scrum) are made by the team.
How to make sure the sprint doesn't slip and that it produces useful product increment? It's easy if a team becomes familiar with the product under development. Or the team can just commit with a safe amount of user stories for each sprint.
So it seems easy for a team, after becoming familiar with the Scrum framework, to deliver a beautiful burn-down chart to satisfy the ScrumMaster and enough product increment to make the product owner happy. Since everyone is satisfied and happy, this seems fine, right? No, because in Scrum we care not only about the output but also about the productivity of the team (including the ScrumMaster and product owner). If the productivity of a Scrum team can be manipulated as desired, or even "cheated," that is not real Scrum, and there must be a problem.
What is that problem? As I mentioned in the beginning, it is the accuracy of estimation. If the estimation can be manipulated, the Scrum can also be manipulated. So it's straightforward for most of us to think, "Can we find some way to evaluate the potential overestimation/underestimation and manipulated estimation? Or can we build a framework with enough constraints and history data to evaluate the estimation?" Although this problem rarely happens, it is possible, and I've been thinking about it for long time with the hope of making some breakthrough in applying Scrum within many organizations. I've also gotten some excellent suggestions from books I've read and experts I've met (such as Arne, my CSM trainer and guide). These ideas include:
- Relative estimation, that is, using story points rather than hours or days, since people are actually not good at estimating hours or days accurately. Relative estimation is much easier to deliver correctly. However, it is still possible to manipulate the story point estimation this way.
- Record and review the velocity of each sprint. As a project goes on, the team becomes more and more familiar with the technology and the product under development, so the velocity of Sprint 5 should be higher than that of Sprint 1. Checking sprint velocity is a great step, since we can take the velocity of each sprint as the metrics of team performance and, more important, we have solid ground on which to inspect and adapt.
While those ideas are good, I still hoped that we could come up with even better solutions. One day, I suddenly noticed that maybe I was thinking in a wrong way, or a not-so-Scrum way. How about another way? A possible and much better solution is to not focus on a constraint framework but to inspire and encourage the team to take the ownership of the project result (no matter how good or not so good), so that the team can be more self-organized and commit to more product increments.
One responsibility of ScrumMaster is to let the team know the project result, whether it's good or not, so that team can actually take responsibility and handle its own self-organization. If the status is good, the team may try to see whether it can make it better by commiting more with better quality. If the current status is not so good, the team can try to improve — also in a self-organized way.
Of course, it is the job of the ScrumMaster to keep the team inspired with high morale.
These thoughts reminded me of a situation I faced when running my first Scrum project. It was in about Sprint 3 that project stakeholders (including the product owner) and I noticed that the release velocity might cause some delay. I looked back into the statistics of Sprint 1 and Sprint 2. The burn-down chart didn't look bad, although we had some slip, but that was caused by some external impediments already solved. The release velocity didn't meet the market-based release plan. The team I worked with consisted of all-star members and everyone was active. So what was the reason and who was to blame?
Actually, in Sprints 1 and 2 we (the stakeholders, product owner, and I) had already noticed the signs of delay, but we had decided to let the team focus on the committed tasks and not add pressure, since it was still the beginning of the project. However, after discussing this with the main members and managers, I wondered if that could be the wrong approach. The action I took was to tell the team that what it committed was not enough and we needed to improve our velocity. After discussing this with the team, we decided to experiment by reducing the span of Sprint 3 from 15 days into 8 days, without decreasing the committed tasks. To inspire and encourage the team, I pasted a big accelerated release plan on the whiteboard just above our burn-down chart. This might sound crazy, but it actually worked. All committed tasks were finished without any compromise in quality. In the following sprints, team members became more "aggressive" about picking up user stories to commit. That's what we wanted to see.
The reason behind this thinking is to inspire the self-organization of the team, and the important precondition for that is to let the team really be part of the project result, whether that result is good or not.