Marco Tedone's blog

One of the values of Story Points in Agile planning

I've been working in Agile environments for almost 6 years now and I still manage to learn everyday! Recently, for instance, I came across one reason why story points are a good measure for planning. We had a list of stories whose complexity the team had estimated in story points; however because we were at the beginning of our release, there was a high number of unknowns (which we addressed by creating spikes). We use to divide a story in tasks and to estimate tasks in Ideal Engineering Hours (IEH); however due to the number of unknowns, we didn't know all the tasks that would make up each story. 

We had on the one hand a list of stories for which the team had a "feeling" about their complexity and which estimated considering the "complexity" of each story, and on the other hand a great number of spikes to identify tasks. 

Thanks to the fact that the team estimated the complexity of each story, although it couldn't estimate all various tasks, allowed us to select the stories to address for the coming Sprint; hadn't we estimated stories in Story Points, we would not have been able to have a "feeling" for how many stories we could have committed to, because the number of tasks actually known was very low. 

Morale: I learned that one of the true values of story points, as a measure of story complexity, is that they allow the team to plan an iteration even if the tasks to complete each iteration are unknown, so they are a great planning tool.

Of course, the outcome of different spikes could very well be that a story is ways more or ways less complex than originally estimated; that could however happen even if all tasks were known when planning the iteration (for instance because a high number of unknowns emerged during the Sprint, or the team realised that not all tasks originally planned were actually required). However having story points allowed us to provide an iteration estimate even if we didn't know in detail everything that was needed to complete that iteration. 

Technical Leaders are graded by multiplication, not addition

Today I learnt something incredibly useful while reading Becoming a Technical Leader, by Gerald Weinberg.

As Technical Leaders we are graded by multiplication rather than addition.Typically there are various dimensions to our grading, technical skills and the so called soft skills being two of them.

Let's imagine that one is very good technically but occasionally has a bad temper. In grading terms, we could say that technical skills are graded at 80 and soft skills at 40. Firstly, the grade of this person is not 80 + 40 but rather 80 x 40 giving a 0.32 instead of 1.2.This becomes more and more interesting as more and more skills are added to the equation.

A more interesting thing to note here, however, is that when grading by multiplication an increase in the skills with the lowest grade has a greater effect than when grading with addition.

With reference to the case above, let's imagine that one was to use addition for grading. It wouldn't make difference if a 10 percent increase happened in technical skills or soft skills, since 90 + 40 = 80 + 50.

However if we were to grade by multiplication, increasing by 10% the poorer skill would make a diffence, since 90 x 40 = 3600 whereas 80 x 50 = 4000.

Lesson learnt? As a technical leader we must strive to improve our poorest skills to increase our overall grades, because we are graded by multiplication rather than addition.