We recently received feedback on an old blog post published by an author who left Clearvision some time ago; in his absence, we asked one of our experts to step in — this one’s for you, valued commenter!
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 into 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 that is both cheaper and faster than 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 provides an expert consultancy service to assist organisations in adopting agile practices and tooling? Click here to learn more about that consultancy service.
clearvisionwebmaster
Atlasssian expert resources
Visit our blog for expert news and articles from the Atlassian world. On our resources page you will find recorded webinars, white papers, podcasts, videos and more.
The Software Blog
Read our blog for articles offering best practice advice written by Atlassian experts, as well as the latest news concerning your software.
Software White Papers and Guides
Dive deep into Atlassian software with our white papers and guides on individual tools, partner products, services, and best practices, written by the experts.
Expert Webinars
All of our webinars are pre-recorded and available to watch on-demand. Enjoy everything from partner features to application demos and updates from Atlassian experts.