Have you ever wondered if there are better ways to estimate work than using Story Points? Below is a potentially simpler, more effective method to prioritise and estimate your software development tasks that could save your team countless hours of debate and confusion.

This mini-article condenses Story Points: Why is this so hard? which proposes a more reasoned and sensible alternative to using Story Points to estimate software development work. If you find this topic interesting I recommend reading the full article.

Key points:

• Slice work in manageable, preferably smaller deliverables.

• Put deliverables in a list with the most crucial ones at the top. Work from the top. In essence we choose to work with flexible scope.

• Stop using Story Points, they are not reliable for scheduling work. (1)

• Working software is the measure of progress. So try to start with end-to-end working software.

Benefits of slicing in smaller feature/behaviour/task slices:

• More accurate to estimate. (2)

• More time discussing actual work.

• More steady delivery.

Of course there is not such thing as free lunch: you need to spend time preparing the stories and accept that sizing the stories will not and does not need to be an exact science. Try not get carried away making the slicing the main activity either.

Thank you for reading, Hans

(1) Story Points were introduced to avoid overworking teams, not estimation. One could statistically derive actual estimates from story points but personally I have never seen it done fundamentally. See Story Points: Why is this so hard? for more details.

(2): In general it does make sense to me since smaller stories tend to have lower variability. Again, Story Points: Why is this so hard? goes into more detail.