It is crucial to manage software projects efficiently, particularly when planning and monitoring them. Software projects are prone to cost and schedule overruns. Researchers at Mckinsey and the University of Oxford studied 5,400 large IT projects and found that, on average, they overran their budgets by 66% and worked 33% overtime. Almost 70% of software projects fall behind schedule and have budget overruns of more than 200%, according to another study of 1,471 projects. To ensure a software project is completed on time and within budget, effort estimation is a critical element of planning and managing the project. As part of project planning, scheduling iteration and release procedures, budgeting, and costing, project effort estimates may be used by various stakeholders. The results of a project may be adversely affected by incorrect estimates. Despite its complexity, the estimation process is integral to software development. A velocity is the work the team can accomplish in one iteration. To determine this, three methods may be used: historical averages, iterations, velocity observation, or forecasting.
User stories are measured in story points. Story points are used to measure effort rather than complexity. A similar number sequence was used in Indian mathematics to estimate story points. Indian mathematicians discovered that trees and flowers exhibit similar patterns. The numbers are 0 1 1 2 3 5 8 13 21 in numerical order. You will arrive at the following number by adding the first two. Essentially, the team assigns a point value to each user story (also known as a story point). There is a relationship between the number of story points and the amount of work required to resolve or complete the task. If there are two story points, the task should take twice as long to resolve as if there are one.
Every team estimates story points within a project. Cohn endorses Planning Poker, which involves each team member estimating, and a consensus estimate is reached after several rounds of discussion and (re)estimation. Each participant is also involved. Every team member participates in planning poker (programmers, testers, user interaction designers, database specialists, etc.). Groups larger than ten are divided into two. The story points developed by a team are based on the team’s cumulative knowledge and bias and may not be helpful outside of the team (for example, comparing teams’ performance across teams). An estimate should consider several factors that influence the effort required to complete a user story since story points represent the effort needed. Factors such as the amount of work required, the complexity of the work, and any uncertainty involved are considered. As a result of an iteration, the velocity is the sum of the story points estimated for resolved issues. If a team resolves four stories, each estimated at three story points, their velocity is twelve. Using velocity, you can plan and predict when software (or a release) will be completed. When the team estimates 100 story points for the next release and its current velocity is 20 points per two-week iteration, the project would take five iterations (or ten weeks). Therefore, the team must estimate their story points consistently to be able to plan and manage their project predictably.
Velocity is a measure of productivity in Agile development. Using story points, requirements, or any other unit appropriate, velocity is calculated as a sum of features delivered and accepted per iteration. The velocity measure provides a practical and straightforward forecasting tool since Agile works on a fixed schedule for each iteration and uses a fixed team to perform the work.
Using story points has several advantages: They foster cross-functional collaboration within the team. Considering that each user story has to be estimated with one number, the whole team must agree. Story points are relative and do not decay. Regardless of the team’s experience or technology, the most complex story will always be challenging. The length of a story point is not determined by its duration but by its size. When it comes to estimating the size of a story, it is easier than when it comes to estimating its similarity. Since story points represent size, it is less risky to compare them to reality because they are abstract. A team estimating in story points typically estimates faster than a team estimating in ideal time. This mindset takes time for the team to adopt, but it is much easier to work efficiently once it has. The ideal day differs from developer to developer, depending on the team or the individual. Story points have the advantage that they can be compared between team members.
Taking an average approach: When you estimate using this approach, you are almost guaranteed to underestimate every time if you’re using this approach to form consensus. In order to settle on an estimate that is well-vetted through thoughtful discussion and analysis, teams should discuss why there is a disparity between estimates.
Deferring to the most senior member of the team: Scrum teams often defer to the most senior member’s estimate, which often results in relatively consistent outcomes. As a consequence of this approach, the lead developer of the project is typically the most senior member of the team, thereby ensuring that the collective effort of the team as a whole. If the team member who owns a user story is not the lead developer, this method of estimation becomes even more challenging.
Skipping the definition of done: Teams often overlook the definition of done. This oversight can result in user stories rolling over from sprint to sprint, unrealistic estimates, velocity fluctuations, and most importantly, scope creep and team frustration. At the beginning of a project, defining what is done is crucial. However, teams often ignore this opportunity in favor of expedited meetings and the quest to return to their desks to do “actual work”. Only halfway through the sprint does the team realize that they disagree on the scope of the user story. Having a clear understanding of what “done” means to each member of the team is imperative, but understanding what “done” means for the entire team is even more critical. We establish the scope of work, place guard rails on the requirements, and monitor scope creep during this discussion.
Unrealistic estimations: A user story should be broken down into a manageable set of tasks that can be completed within a sprint. Correctly estimated user stories are likely to be completed, and completion demonstrates a sense of accomplishment. When an underestimated user story rolls over for multiple sprints, it can be extremely discouraging for a team. As a result of this anti-pattern, there are a lot of frustrations and difficult discussions with management.
One day equals one point: There is no relation between a point and an hour or a day. Every effort has value, and that value can be any Fibonacci number. It is imperative that the team members have a clear understanding of what one day represents. In addition, it is imperative that they understand what it means to the entire team as a whole. Even though story points are not absolutes, they represent a starting point for discussions of the scope and definition of done, since the team has adopted them as a standard.
Keep your estimates relative.
