Measuring progress in a Software Engineering team happens in many different ways.
Often, the short description of a story leaves a lot of ambiguity about the scope of the change. Even when it is being discussed face to face, it may only be plain to the full implications of taking on the story
Valuable initiatives produce an observable change in someone's way of working.
Capturing a behavior change makes a story measurable from a business perspective, always opening up a good discussion.
If you have a big chunk of work, identify underlying assumptions and think about the easiest way of proving or disproving them.
Design experiments around those assumptions and turn them into user stories.
The industry's most common way to measure progress is through story points.
Story points measure effort, not time.
Focusing too much on time will make the team focus on low-value stories to complete the sprint. This is misleading, of course, because the main focus of a delivery team should always be business value.
Working software is the only proof of progress, not any burnout chart.
The problem of measuring effort is even more complicated when presented with bugs. Measuring progress with an activity creates a wrong set of incentives for prioritization. Bugs, by definition, happen when our understanding of the problem is more profound than we expected. This problem is unavoidable.
Software is never done because we need to maintain it.
We can measure what we do in a way that gives us the highest rate of predictability. Activity metrics are great for measuring whether the team works well together, but they can't show real progress.
Focusing on the behavior changes the feature or application tries to influence is more valuable.
Suppose the team is incapable of dependency or needs to provide the expected functionality.
In that case, the team is not the right for such functionality. The user story should be removed from the backlog when we face this situation since it will not impact the business. The team needs new members with the required knowledge.
Instead of estimating, start with a budget for operational costs and time. This budget can serve as a design constraint for the delivery team, such as scalability or performance.
Instead of asking, "How long will it take?" it's better to ask, "When do you need this?" and "How much can you afford to pay for it?" This way, the delivery team can create a solution that fits these constraints.
Most businesses need help to develop an accurate financial estimate of the value of a project.
So, it's better to ask about extremes, such as "What is the least amount of money this project needs to earn to make a reasonable impact? How much would everyone say that this was worth it?"
Story sizing is a common cause of heated debates in online forums and can be a stumbling block for inexperienced teams.
All these estimates are then added to predict when the larger piece of work will finally be delivered. Assessments should be as accurate as possible but only as precise as necessary to keep the estimation cost low.
Don't Underestimate.
Even if you've worked on the same task in the past, nuances are always involved in each study.
Separating large tasks into smaller ones improves the accuracy of estimates. Decompose estimates into tasks requiring at most two days of effort.
Estimate in ranges: worst case, most likely case, best case for a task.
Document and communicate the assumptions embedded in your assessment. Next time someone asks for an estimate, grab a Post-it and take note of your answer.
The best estimation techniques for small projects tend to be "bottom-up" based on estimates created by people who will do the work.
When you are ready to begin the task, start a clock and see how long it takes to complete. Once the task is done, note how many hours it took. Repeat the same thing for the next task.
Group estimation is used in Agile software development to estimate the effort.
The goal is to arrive at a consensus estimate based on the group's collective knowledge and experience.
Relative estimation: this strategy compares items. It is more accessible than trying to estimate their total size.
The team will assign a comparable size to each item, such as small, medium, or large, and then use that information to focus on the backlog. This allows for easy comparison and consensus-building.
Three-point estimation involves estimating each item's required Low, Medium, and High effort. This helps provide a rough estimate of the necessary action and helps plan further.
The Delphi method is used when the team members are present at different places. Each team member will give their estimate using this method, and then the calculations are collected and discussed to reach a consensus.
Most agile estimation techniques are based on time or effort, which can create the wrong incentives for team members. The only accurate measurement of progress is delivered software, which can be objectively measured by the behavior the system intends to change in the user.