How to measure requirement?

[borys....@gmail.com]

Hi!

First of all, thank very much for Agile Workshop conducted on 31.
March in Kiev.
There is small question that I would like to escalate here in
this forum. Serhiy have mentioned so called PLanguage, invented by Tom
Gilb from IBM as mean to estimate requirement. It was introduced as
part of Evo

I'm not much experienced with measuring requirements (I mean not
subjective expert assessment) but retrieving numeric metrics. I used
so called Function Point Analysis (the best introduction given here:
http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm) whihc is
good for simple business application with predifined user interface
and data structures.

My question:
have you ever tried to measure requirements?
what methods, methodologies have you used?
does any agile suppose to measure requirements?
what is pro and contras to measure requirements?

Thank you beforehand!

[Serhiy Yevtushenko]

2007/4/1, borys....@gmail.com <borys....@gmail.com>:

Hi!

     First of all, thank very much for Agile Workshop conducted on 31.
March in Kiev.
     There is small question that I would like to escalate here in
this forum. Serhiy have mentioned so called PLanguage, invented by Tom
Gilb from IBM as mean to estimate requirement. It was introduced as
part of Evo

Hi, Boris.
There is a little misinterpretation. (maybe I was not quite clear)
Planguage is a mean of doing requirement quantifiable (and measurable, how well the requirement is achieved). Planguage does not deal with estimation of size of requirement.

 

Serhiy

[Alexey Krivitsky]

Borys,

> My question:
> have you ever tried to measure requirements?
> what methods, methodologies have you used?
> does any agile suppose to measure requirements?
> what is pro and contras to measure requirements?
>

Thanks for being with us on the workshop.

Let's start with the goals not methods.

Why one may need to measure requirements?
Probably to see what can be project's timeline, or effort needed.
Most of the projects need to answer such questions (with the except of
the internal-style projects that Alexey Maslov described explaining
user stories).

To answer the question of the timeline/effort I use expert estimates
as story points
in collocation with iteration velocity metrics. Visualizing this on a
release burndown chart does its job.

This is pretty what I explained on the workshop on the topic of agile planning.

This is somehow a good-enough practice that doesn't take too much time
(comparing to e.g. FPA) and gives results that are accurate enough to
answer the major questions but still quite rough from the other side
that helps avoid any hard promises. Exactly that I need.

What are your case, goals?

// Alexey

[borys....@gmail.com]

Well. My nearest goal is to make requirement measurable.
My further goal is to collect enough statistic of time/effort from one
side, to requirement metrics from another side and make project time
line PREDICTABLE.
Currently, only thing I can do is to make rough estimation (or quite
precise, but still not reenforced by arguments) estimation. That might
be not enough for the most of the customers ...

Burndown chart can predict project time line under two conditions:
1) Project is already running
2) Customer won't change requirements inhomogeneously

I'm looking forward to see something independend from this
conditions ...

Regards,
Borys L.

[Michael Vizdos]

Figure out how many "story points" you are burning each iteration (as
a velocity). Not hours completed.

Then look at your product backlog and have the team assign story
points to each of the remaining stories. Viola (smile)... that easy!

OK... not super simple to do; however, by using story points for
estimating the stories will usually give you and the team a relative
best guess that can be frighteningly accurate!

- mike
www.michaelvizdos.com
www.implementingscrum.com