Going Beyond Story Points
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.
Use the experiments to build the foundation so that the rest of the big picture can be delivered with minor iterative improvements. If a story does not fit into the expected pattern, raise the alarm early and consider re-writing it. Micro-stories are alright, but going so deep into detail is overkill for things apart from short-term plans. Even planning to check the outcome after delivering a story makes teams write better. It has the same effect on code as test-driven development. It provides focus and clarity and leads to better solutions. Users are not concerned about how we do such a task. They care about results. Teams often divide the work and look for chunks that still have value. User Stories define rules that are important to customers of the system.
