319: Effective Strategies for Accurate Project Estimation in Agile Development

Estimations should be as accurate as possible but only as precise as necessary to keep the estimation cost low

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

Thank you for checking out the free preview of Snippets of Text. Please consider subscribing to the paid version if you find my work helpful. This will allow me to dedicate more time to developing new ideas to share with you.

Enhancing Software Design for Changing Business Needs

Designing software is a continuous process that needs to adjust to the system's evolving requirements. We must balance efficiency and maintainability, which often involves choosing between procedural and object-oriented code. When we need to switch between these paradigms, refactoring becomes a valuable tool that lets us enhance the software design in response to the changing business needs.

If a design is causing problems for the development team, something important is likely missing. There are various indications that a design may need to be more flexible. Still, the most evident is the difficulty in testing an object, which often points to coupling. It's essential to keep an open mind and be receptive to design insights during the coding process. By working closely with the code, developers can simplify the system and make it more straightforward. 

The performance and functions of a software system depend on its behavior. Specific systems require greater flexibility. Design should prioritize flexibility over aesthetics. Premature decisions about application structure should be avoided. Decisions should be made based on business relevance. Good design, not personal preference, should be used. 

Effective Strategies for Accurate Project Estimation in Agile Development

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. 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. 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. Measuring progress in a Software Engineering team happens in many different ways. 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. The User Stories should be removed from the backlog when we face this situation since it will not impact the business. 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. It needs new members with the required knowledge. 

Instead of estimating, starting with a budget for operational costs and time for a significant work project is recommended. 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 make 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.

I invite you to upgrade to a paid subscription. Paid subscribers have told me they have appreciated my thoughts & ideas in the past & would like to see more of them in the future.