Everybody knows how important planning and estimation is inside a Scrum development cycle – it helps the Scrum team to communicate and break the User Stories down into measurable pieces; it helps to estimate how much work the team could finish within a short period of time so that team would make commitments that they feel comfortable with; it also helps to establish the basis for tracking and evaluating, and establishes the team’s velocity.
But what is the best way to do planning, especially estimation, for one specific project? From my point of view even when we bring that question to an experienced Scrum team it’s still almost impossible to know the answer before they really deliver something – it’s less likely for a team to have a universal estimation model to fit all the different business solutions, technologies, clients, and time; or at least it’s less likely for them to be able to select the most suitable estimation technology from their toolbox in the first sprint. The reason is kind of simple – the project nature and basic characteristics decide that every project varies from another.
But we still do estimation in our first Sprint. In one of my previous projects, we spent 6 hours for our first 3-week Sprint, to finish reading through the necessary material and discuss around the details, based on which we then did task break down and hour based estimation for them. The whole team was tired up after that long session, and a little frustrated – we were not confident about the outcomes since there were so many new technologies that team was not familiar with, and we were feeling that using hours probably was not the best way we do estimation.
Unfortunately our concerns came true after we finished the first Sprint. After we failed to deliver the planned work we realized that probably Story points fits us better – different team members have different levels of knowledge on the new technologies and the estimated hours became meaningless when different people picked tasks up from our Sprint backlog. In the Sprint retrospective, a junior guy raised an interesting question that nobody could answer: “Since most of the estimated hours were wrong and nobody was feeling comfortable to commit on those numbers and finally we decided to change to story points, why didn’t we just skip the estimation session until we got enough sense of those tasks?”
That question gave us an idea on how we do estimation for our first Sprint more effectively, if the team is not comfortable to calculate the estimation and commit on them – we just don’t do it. We still collect effort data so that in the next Sprint we can learn from those data and make the decision on what the best way is to do estimation.
I practiced that approach in another project. In Sprint 1 we skipped the estimation on purpose, but we still did task break down, and the team built a spreadsheet to record all effort we put onto each specific task.
In the Sprint 2 planning session, the first thing we did was to have the whole team go through that spreadsheet. We picked up those special points and analyzed the root course, and then we made a team decision on which metrics the team would be interested in using in the following Sprints. All team members agreed that we should go with Story points, and then it became easier to finish the rest of steps in quite shorter time.
We value estimation and believe it’s one of the key technologies we utilize to keep our projects on track, but we should also use that technology in an Agile way. Remember estimation is never accurate. The more we practice by delivering real work, the closer we get to a steady team velocity, and that takes time. That’s why I would suggest we put “not doing estimation in our first Sprint” into our toolbox as well.
