Select Sidearea

Populate the sidearea with useful widgets. It’s simple to add images, categories, latest post, social media icon links, tag clouds, and more.

Agile project management for Architecture.

Evaluate user stories complexities

Evaluate user stories complexities

Planning poker - Agile Method

Agile methods and scrum are focused on providing all people implied in the project a feedback loop to allow team members and client to have a good estimate of what the team can deliver.

The evaluation of difficulty of tasks if important as we do have not all the same viewpoint of what is difficult and what is not.

Agile and scrum use gamification Technics to make this otherwise arid estimation task a fun and efficient process.

Let’s explore estimation of users stories in more details.

why evaluating the difficulty of the user stories

Evaluating the difficulty of user stories of our Sprint is an important activity to do before starting actually the Sprint.

It has several benefits like :

  • compare user stories difficulty

To quickly adapt what we think we can do.
for example let’s say a team member is not available full time in the Sprint. He may assign him self stories that are more simple

  • track advancement :

one of the scrum table (burndow chart) use directly the complexity points assigned to user stories to display advancement. We will talk about agile charts in a later post, but without estimation it is not possible to have this great visual information.

  • force to anticipate complexity :

    user stories estimation are like a contract between the product owners and the delivery team. You pledge to finish all user stories in a “done” and accepted state within the Sprint. But this imply to participate actively to Sprint planning to help product owner to evaluate what is hard or simple to do. Indeed technical works seems complicated but could be simple and the reverse could be true as well. So delivery team need to read the user stories description more in depth, and raise some alert if a point may have hidden difficulty.

  • estimate the cost of the added value for the final user :

In agile methods what is important is focusing on the final user added value or business value. The technical value is only a way to achieve this goal.

So each piece of user value have an associated complexity value to make it real that need to be “paid”. And it is an essential things for hiérarchisation to be able to know the user value provided (important, not important, essential) as well as the cost to build it (the user stories points).

So once we know estimating is a good thing and not a burocractic old fashioned method asked by unfriendly project manager.

Which point system to use : estimated hours, linear point system, Fibonacci suite points…?

The response is up to you as long as you stay consistent as to compare Sprint we need a standard metric. We will explain you in the next paragrapher a popular point system in scrum methods and why it is a good option.

the point system of scrum methods : Fibonacci suite

points vs hours

Estimation in hours or days seems more natural in project management as we can actually track this metric with time tracking app or just by analysing where we spent time.

But the problems with hours or days is that it give you a false sentiment of exactitude. Despite in real projects we all know some tasks that seemed simple lasted far too much to be completed and at the contrary task that were quite intimidating last less than expected.

Also giving hours could end up with a sentiment of culpability if you spend more time than estimated.

With points it is different as we cannot directly associate a point with real activity. It is a bit the same that the “false money” or using foreign currency in a foreign country we do not know. By removing our reference system, it force us to get more relaxed about estimation.

non linear points vs linear

But why not a linear point system : 1, 2 , 3… ?
Instead scrum use an well known mathematic suite : the Fibonacci suite.
It start slowly then get high quite rapidly in a similar way than exponential curve.
So it means that first number are very close to each one and the last get distant.

But why and how to use it ?

The idea behind this choice is to assume that estimation are only estimation and that what is important is too differentiate clearly what is simple from what is difficult. Practically 8 is a medium difficulty task. All numbers under 8 are considered easy tasks. All over 8 complex task
Practically number from 1/2 to 100 are used

A benefit of having high values for complex tasks is that it highlight the difficulty especially for product owner that not always figure it out. And also it helps take into account we often underestimate real complexity even if we feel something is complex.

a fun way to ask you team : the planning poker

How to decide of user stories complexity

The scrum master in his desk ? Not compatible with agile method principles. The team know better what it takes to accomplish a task. But no one have the full story. We have each one different vision of the task depending if we are used to work on similar one or not. So the ideal way is to vote for the estimation. If you have no element to estimate a task, it is better not to vote. Also the final choice is not an arithmetic moyenne of people vote. But the result of the discussion after the vote. So probably people who are going to work directly on it will have more credibility.

But how to do this vote ?

You can do it with manual means : post it. The important is that people do not know the rest of the team vote as it would influence them.
But there are good online tools that allow to do that. There are obligatory if you work with a remote team.

So the scrum master add all users stories of the planned Sprint. He read the description of it so everyone is aware of it. Then he open the vote for this specific user stories. Then we know the vote of each one. If there are no big difference, we generally take the vote that most people did. There are pie chart that allow to easily see the vote répartition.
At the contrary, if there are very different votes like 2 peoples that estimated 5 and 1 20 and the 3 remaining 8. We may ask the team member that voted 20 and the one that voted 5 their view point. May be the mistake because they missed a point. May be they know a complexity that other do not know.
If the discussion ended with a reconsideration the team can vote again to actualize their vote in order the team can converge to a reasonable estimation.

Thanks to this voting technic we can take profit of the team collective intelligence. The team has the responsibility of the estimation so it accept it also which is very different from traditional top to bottom estimation. And finally it is a good moment to talk about user stories and exchange point of views.

Want to try agile method with one of your architecture projects?