Whether you follow a Agile framework like Scrum with its planning poker or a traditional project management approach, the estimation activity is always difficult to perform productively and consistently on the long term.
In Scrum the estimation effort and accuracy depend on the team. In this article, Jingjie Wang discusses the situation where the Scrum team tends to underestimate its capacity to deliver so to be sure that the product owner and the scrummaster are always happy at the end of each sprint because everything promised is deliver.
In this article, Mitch Lacey discusses the difficulty faced when trying to provide estimates for software development project. The beginning of a software project is the time when you are the least certain about the final scope project, but it is also when you are asked to deliver precise estimates. Agile tries to move from uncertainty to certainty in as quickly as possible.
Developers don’t like to provide time estimates for implementing a software feature. Management, on the other hand, has a legitimate need for project management estimates. This article explains how the Scrum Agile Project Management framework provides a solution to this conflict.
The first step in creating a useful Agile project plan is the ability to estimate reliably. Mike Cohn discusses how to do this. He explores various approaches to estimating in Scrum including unit-less points and ideal time. The class presents four specific techniques for deriving reliable estimates, including how to use the popular Planning Poker® technique and other techniques that dramatically improve a project’s chances of on-time completion.
This article discusses estimation techniques for teams that are adopting Scrum. The authors recommend to use story points during the release planning phase, but initially to switch to hours to estimate tasks during the sprint planning. Then the team will gradually move to using story points to estimate complete stories that members will commit for in next sprint.
This short presentation explains why software metrics are not the panacea that we thought they might be 20 years ago. This is why moving from a predictive model to a reactive approach is the only rational course.