Expert Atlassian consultant, Nigel Budd, voices his opinion on the importance of size over complexity in Story Points.
The problem with the old article...
The blog in question was about Story Points, which are usually a measure of size; teams learning how to estimate using Story Points often refer to abstract sizes such as dog breeds to help them learn. Discussions can differ between whether a User Story is a Terrier, a Border Collie or even a Great Dane!
The original article argued that complexity has a far greater impact over size, when it comes to the amount of time a unit of work takes to complete.
A piece of work performed several times over e.g. a piece of code to create, view, update a record, may be considered large, but this doesn’t mean that it’s complex. In fact, such works are often deemed low-risk, making them more likely to be produced at a faster rate.
On the other hand, a small piece of work considered complex can take a while to introduce; most developers understand the damage a single change to a line of code can have, not to mention the amount of testing that can follow a small change to a shared component. So, when it comes to estimation, complexity has got to be a factor, but I don’t think size can be ignored when it comes to estimation — a large piece of work may simply take a long time to do.
Let’s say you can’t polarise estimation by using size or complexity, and therefore need a mixture of both. A lot of teams overthink Story Point estimation, and there are often long running debates over size and complexity, the impact of the phase of the moon, football results, and so on.
Estimation really boils down to something quite simple — how much work is involved. Sprint planning really comes down to how much ‘work’ can be fit in to the next increment. If it’s a small piece of work, it needs a lower Story Point value, and if it’s big, or complex, it needs to have a higher Story Point score.
Size and Complexity
Quite a few teams think it’s okay to commit to delivering large or complex items of work in a Sprint. This is necessary sometimes, but whenever anything large or complex is required, it adds risk to the successful delivery of Sprint goals.
If a team identifies a story as complex, it’s often a good idea to ask why, and then follow up with a way to mitigate the complexity.
‘Spikes’ are often used to research areas of complexity; a lot of the time, something that’s complex isn’t really understood, so maybe the requirement itself should be challenged. Sometimes an easier solution which is both cheaper and faster to what the business originally asked for can be found.
Large items should be broken down if possible, into smaller deliverables for greater value to the customer at a faster rate. This also means feedback can be gathered to validate the solution, ensuring it is in fact what the customer needs.
For further advice on estimation practices, try the following books:
Scrum – The art of getting twice the work in half the time – Jeff Sutherland
Agile Estimating and Planning – Mark Cohn
Scrum and XP from the Trenches – Henrik Kniberg
Did you know, Clearvision provide an expert consultancy service to assist organisations in adopting agile practices and tooling? Click here to learn more.