Why are your apples not the same as my potatoes?

We’ve already mentioned that the developers at Miway live out Agile methodology. A distinct part of Agile is “relative sizing” – a method of estimation used in Agile teams. The Agile Alliance Guide defines relative sizing (or relative estimation) as estimating tasks or user stories - not separately and in absolute units of time, but by comparison or by grouping of items of equivalent difficulty.

“Relative sizing” has changed a lot in the past few years with everything from story points to effort points …to no points and “only story counts”. In this post written by David du Toit, senior developer at Miway, ‘relative sizing’ can be read as ‘effort points’.

Within one team, a sizing of 5 could mean different things for different team members. On top of that, the effort sizing of “5 points” is also relative when comparing effort between different teams. Developers, testers, scrum masters and product owners in the same team will (pretty quickly) learn how to size relatively and in the same manner.

However, the amount of effort points needed for a story is not always that apparent to non-regulars attending this same team’s grooming or planning sessions. To them, a 5 is half of a 10; a 1 is closer to a 2 than a 5 is to an 8 ...and “obviously all you need to do is size smaller, don’t you?”.

Firstly, you need to ask the question: Has anyone helped them understand WHY the team decides on a certain sizing or what it could be used for? And then, the ten thousand rand question: Would the same explanation work for every type of person? Think of relative sizing as a measuring tool. All professions have at least one measuring tool, so if you can compare relative sizing to that, then you should be able to get somewhere.

Possible misconceptions may be held by financial stake-holders, who could be anyone from financial specialists to actuaries:

• "Relativity” is clear to number-crunchers, though misunderstood: to number-crunchers, 10 points is double to 5 points; 10 points are a tenth of 100.
  Explain your scale of estimation: if the team uses the Fibonacci sequence, explain why. The theory seems to be that the larger the story is, the more uncertainty there is around it and the less accurate the estimate will be.  
• The presumption that individuals size for themselves, or for what they believe would be the smallest size if the “best” person works on it.
  Explain that the 'sizing' per story is decided on by every member of the team - based on past experiences and how much 'effort' would it take the WHOLE team to work on and finish the story.
• Another misconception is that there is a straightforward line of starting with a problem and working towards a solution – how long this solution takes to implement has a direct correlation on the amount of effort a story entails.
  The key to this is to explain what the various team members need to do in order to get the story done. Will the Oracle devs have to get the 'back-end' of the story done? What work will the PHP devs need to do? The process of testing the story should also be highlighted. Don’t forget the effort for writing unit tests, behat tests, informing teams of changes to a shared code base (teams who have their own backlog, testing, etc.), regression testing, and so on.

The world of call centres is a different place with different people and different rules. It's one of those places you need to experience before you can even start to understand it! Stakeholders from this world do understand the complexity of having multiple people involved in getting to one outcome, but they hold some misconceptions:

• Comments such as “Similar types of stories should become less and less effort as you get more practice!”  or “We need your team to increase by at least 3.5% in story points per sprint!” may be heard.
  Explain how the team’s “velocity” is used to enable the product owner to forecast when work may be done. Velocity is determined by a team’s consistent completion of stories and the 'burning' of the story's effort sizing. Usually, explaining the use of the “effort point” and the benefit that forecasting holds is enough to alleviate the stress of not understanding the relativity of the sizing.
• “Something similar was done for a previous story, so this one should be simple!”
  A good method to motivate the sizing of a current story is to compare it to a story done in the past of the same size. Comparing stories of the same size to determine whether the team's relative sizing is accurate is always a good thing to do whenever any story sizing occurs! A previous “5 point story” which has been done and deployed will give reference to the effort it took to build, test, demo, sign-off and deploy. The relevance helps to explain the similarity of the stories - but also what might be different.

To summarise, using elements from a stakeholder’s professional background will go a long way explaining the value of WHY the team needs to size a story. Even if the stakeholder might not entirely understand HOW the story is done, future misconceptions may be avoided and greater understanding achieved.