The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
There are many variables to estimating the difficulty of a code changes. We could talk about things like the complexity of the code (Cyclomatic Complexity), the experience of the programmers, their familiarity with the topic and/or the specific module, the quality of documentation, etc. It ends up being a fairly subjective estimate. In Scrum teams, story sizes are estimated in relative terms in terms of story points.
The primary benefit to using a technique involving Relative Estimates is that you are asking the team to give you an estimate of difficulty relative to other work that has already been completed. This means that a team can easily give judgments like “This will be twice as hard as that” and come up with functional estimations for predictions without spending a great deal of time coming up with them. Estimates are just subjective guesses anyway, understanding that can be a valuable way to put more time into building something and less time into trying to guess how much time it will be to build it. Planning Poker, also called Scrum poker, is one technique for building relative estimates and for coming to consensus on the effort or relative size of the stories.
Leave a Reply
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013