Ready for More?
See the results of my work.
Discover PyraCloudRecently I had some time off and used part of it to take a closer look at additional ‘agile’ blogs, forums, and community resources. I found a post that came from one of the agility consultants I know. It made me think about writing a blogpost about estimating within agile frameworks like Scrum or Kanban (or outside of them, but still in an agile manner). This topic is quite tightly coupled with one of the estimation techniques – relative estimations. I decided to share my experience as I found various misconceptions, but also a lot of value using those techniques.
What is a relative measure (of estimation)? I found a good description of one of them in Derek Davidson’s article and adjusted it a bit for the use of this article:
“Relative unit of measure is a unit decided within a team to provide relative estimates of size of requirements and effort needed to fulfil them.”
Doesn’t explain much, does it? No worries – if you work on a product in an “agile” manner there is a high chance you use such techniques or have at least heard about them. When you ask yourself what’s a relative measure, think about key messages of stories, t-shirt sizes, and similar topics. They are relative, because they need to be compared against something. Each of them needs a certain point of reference that is sized using the same technique and is not described in time units. Why is that important? Because translating it to time units makes it as absolute as time itself, so the whole idea of being relative is gone. There is no point in such translation, because you can use only time units – adding another level of abstraction only increases unnecessary complexity.
The way relative measures are used is that when you need to estimate something (user stories, features, whole backlog, etc.), you discuss the item and the team votes about the size. Because you have the point of reference this is straightforward – if something is smaller, give one unit less than the reference. If bigger – one unit more. Much bigger – two units more. Units can vary a lot – I personally prefer Story Points (SP) using Fibonacci sequence – 1, 2, 3, 5, 8, 13 and so on. It shows that if we want to estimate really big things – the difference between a smaller unit and a bigger unit also grows, as unknowns also grow (dependencies, risks, etc.). In general – the smaller, the more accurate.
Why just not stick to time units and do as we always did? Well, relative measures solve a bunch of issues you might face when trying to estimate in time:
As for now we have discussed the mostly positive impact of Story Points (SP) to the development team’s and Product Owner’s life. But are there any drawbacks? As usual – there are a few:
Misuse, misconception or misunderstanding can also hinder positive effects of relative measures. One of them is translating relative measure to time units I already mentioned earlier in the article. The other things I observed, experienced, or heard about are:
Relative measures can be a great help not only to estimate how much can be done within short period of time, but can also help with longer term backlog planning, monitoring effectiveness trend of the team, improving knowledge sharing, understanding complex business or technical domain, indicating problems (e.g. when velocity drops rapidly) and lower estimation costs. To use them properly, it is advised to follow some good practices:
At SoftwareONE we are living what we preach. As one of the leading IT service provider we are working in an agile manner to develop the best software & service solutions for our customers. I personally work in the development team for PyraCloud, our proprietary digital platform which provides customers with data-driven, actionable intelligence to manage and optimize their software and cloud spend. In this area we use Scrum to deliver value to our customers frequently and learn from this.
Watch our video to learn more about our digital platform PyraCloud and how it can optimize your software estates from on-premise to cloud
Leave a comment to let us know what you think about this topic!
Leave a comment