SCRUM RESOURCES

Estimation Using Scrum Well things do not change just because we have used SCRUM. You do not get any additional information just because we have adopted SCRUM. The estimation technique is quite similar to what we have been used to. It is just that it is simpler and fairly accurate. I would like to ask you to think about a very fundamental question Who should do project estimating in a software project?

The project manager? The Architect? The coding team? The UI team? The testing team?

Who do you think is a key in the estimating process? Most often the project manager and the architect sit for half a day and come up with a rough kind of estimate. The fundamental aspect of SCRUM is that the team that is doing the job should estimate the project. I repeat the team which is commissioned for the job is the team which should do the estimation and not any body else. Not the PM, not the architect, not a team which is working on another project, no it should be done by the people who are supposed to execute it. The fundamental difference is ---- involve everybody you think would be part of the project. Everybody meaning, the system administrator, the business manager, the design department, the testing department, the programming community et al. I repeat EVERY BODY WHO WILL POSSIBLY BE INVOLVED IN THIS PROJECT AND HAS A STAKE IN THE PROJECT. DO INSIST THAT YOU HAVE THE PRODUCT OWNER AS PART OF THE ESTIMATION PROCESS WBS with a Difference

Do a high level WBS on the project and come up with various elements of WBS. Be careful not to have a WBS which says Design, Testing and Coding. Your WBS should be feature oriented and not process oriented. The first step is to break your requirements into user stories. User stories are description of a given functionality which make sense to a user. It is a piece of functionality which has a functional flow and can be delivered. As a team we tried to break the requirements into user stories. Our team had no formal experience in breaking requirements to user stories. We followed the simple guidelines:

As a user what should he do to achieve a desired outcome? Can this be treated as a complete functionality which is of a unit level? Try to reduce dependencies while building a user story

Examples: As an administrator I should be able to create multiple roles for users and they should be able to access certain sections based on the roles As a user I should be able to search using the following parameters and my search results should be sortable, paginated etc These user stories were used in estimating the effort. We did the estimation using pointrons and played poker. Playing Poker: Every body comes with a set of points to estimate the project. Points denote three aspects

Effort involved Uncertainty involved Complexity involved

The points are on a scale of 1- 50. Fifty being very complex and one being very easy. It may be a good idea to run this exercise with a project which is known to all the members so that they understand what this point based estimation is all about. You may be surprised with the variation that the team comes up with. The key idea is to surface the variation. Encourage people to talk about the variation. Ask the following questions: Why do you think you feel that this should be allotted 40 points whereas your colleague says it needs only 13 points? Facilitate more discussions, record the assumptions, and ask the team to arrive at a consensus. If they cannot arrive at a consensus, ask them to live with certain uncertainty and let them come up with a figure that they can live with. The reason I found this exercise useful is because it surfaced the following issues:

Key assumptions which have a considerable impact on the project were surfaced Team members got involved and the estimation came from the team members who most probably will work on the project. Compare it with the estimation done by you, your project manager and a few senior resources

The product owner or his representative is around to clear a lot of assumptions and cobwebs

You used points in favor of hours. Points being a new unit of measure the bias of padding the hours has not yet surfaced

From my experience, self and our business manager, account manager found this information extremely valuable to meet up with the client and get some of these assumptions vetted. This sort of stuff never happened earlier. We were only told - make reasonable assumptions, you have the experience.

There was a significant buy in from the business manager and account manager about the problems we were going through and the importance of clarifying the assumptions. There was no one-upmanship. In terms of translating these points to a time line, the team came up with hours for features which were fairly simple and where there was a good understanding of the modules. We used these hours and extrapolated the rest of the user stories to arrive at the number of hours needed. Example: Role management which was worth 40 pointrons was estimated at 60 hours and Search which had 55 pointrons was estimated at 80 hours. You average the pointrons versus hours to come up with a rough estimate of hours for each user story. This was followed by some out of dependency tracking and the usual pert chart to see how the project can run in a concurrent fashion. We did not put too much rigor into it but then the whole exercise gave us a rough kind of time line. The surprising aspect was the time line was about 50% more than our initial estimate. It was kind of hard to swallow but we forced ourselves to go with it. We had tough time convincing the business manager, but the good part was that he was part of the estimation meeting and that made the discussion easier. We repeated the same exercise for a project that was well under way with a different team and the results showed that our estimation was in variance with the team estimation and indicated our estimates were off by a significant degree. During our project implementation we did revise our estimates, we did them as part of every sprint and our estimates were never off by more than 10%. Our project finally over shot the schedule by about 5%. The final upshot is that estimation will vary based on who is doing it and it is better it is done that way as you have a buy in from the stakeholders.