0

I'm preparing a presentation about Agile methodology for managers (not programmers) and I'm looking that, from a side, the Agile talks about functional perspective*^ (in Scrum we have planning game) but, from other side, it lacks any (standard) definition of **functional measure.

In my opinion it's strange: how I can give a magnitude of effort by functional needs of user if Agile methodology doesn't use a formal/univocal definition of functional needs and doesn't adopt any formal functional measurement (Function Point, COSMIC).

If you have played to planning game or User Story, what was your measure unit? Have you used the FP or COSMIC?

alepuzio
  • 341
  • 4
  • 15
  • Planning game doesn't tell you metrics. It just tell whether something is easy or difficult to do (on a scale). – BЈовић May 12 '13 at 21:45
  • Rigth, but the planning game is used for estimate the effort of buindling deliverable software. For my presentation, I need to linking the Agile methodology to software measurement (better, functional software measurement). – alepuzio May 12 '13 at 21:50
  • Every estimation is a guess. Experience might help you make a better guess. As far as I know, there isn't a specific agile practice that helps improve the guess. – BЈовић May 12 '13 at 21:55
  • 1
    In your planning game, are you using story points? We find that "number of story points delivered" is quite a good measure. You can actually track a burndown of story points just as well as you can time, only time is often too fine-grained and thus hard to capture. – guysherman May 12 '13 at 21:56
  • As far as I understand Scrum, the results of the planning meeting should be decisions what to include in the next sprint, not estimations of effort. A team could just as well do no estimation of effort at all. – Patrick May 12 '13 at 22:02

1 Answers1

1

The planning of a scrum sprint has two components. On the one hand, you estimate the complexity of the stories and tasks on the backlog in the unit of Story Points. More on that later. On the other hand, you how many story points the team can deliver in one sprint. This is called the velocity and it is based on the historical data of how many story points the team delivered in the previous sprints. Here, you can also factor in things like known absences, due to, for example, (public) holidays.

Story Points are a relative measure indicating how much effort a given task will need when compared to the other tasks in the project. The first few times you may need to designate a simple (but non-trivial) task as 'reference task' and define 1 Story Point as being the effort needed to complete that task, but after a while people will start saying: "Hey, this task/story looks similar to that one we did two sprints ago. It should have the same number of Story Points."

You should be aware of the risk of Story Point inflation. This is a risk with people who are used to estimate effort in manhours and it happens when they start giving consistently higher estimates than before, because previously they forgot to factor something in (for example, testing). If you consistently forget to factor something in in your Story Point estimates, then you should not adapt your estimates because the fact that you consistently forgot something will express itself in the velocity of the team, so adapting your estimates results in a double compensation.

And for managers especially, it is folly to think you can compare Story Points from different teams. If you have multiple teams working on a project, it is very well possible that their velocities differ by as much as a factor 3, but that the team with the lowest velocity number produces the most value, just because their unit of measurement (the Story Point) is so much bigger.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179