Planning Game and Tracking Velocity

Expand Messages
• Question. I m about to start playing the Planning Game in earnest, and I ve discovered that my little lab notebook doesn t *quite* impose enough structure for
Message 1 of 8 , Jan 31, 2001
Question.

I'm about to start playing the Planning Game in earnest, and I've discovered
that my little lab notebook doesn't *quite* impose enough structure for what
I need. I've tried using an Excel spreadsheet, but that's even worse. When
I *do* remember to fire it up, I can never get the time formulae to work
right.

I've convinced my manager to let me play the planning game and track
velocity as an experiment to see if my estimates and scheduling is/gets any
better than the currently standard SASTW* model.

* ShrugAndSayTwoWeeks

I've heard several opinions on this group that writing time tracking
software just isn't the way to go. It does strike me as not being the
SimplestThingThatCouldPossiblyWork.

So, I'm wondering... does anyone have any paper forms they use regularly?
Something that lets them keep track of

(*) What needs to be done
(*) How long that's expected to take
(*) What got done
(*) How long it actually took

with an eye towards being able to easily calculate velocity and such?

Thanks,

-dB
--
I don't know or trust Demeter.
• dbrady, ... d So, I m wondering... does anyone have any paper forms they use d regularly? Something that lets them keep track of d (*) What needs to be
Message 2 of 8 , Jan 31, 2001

d> So, I'm wondering... does anyone have any paper forms they use
d> regularly? Something that lets them keep track of

d> (*) What needs to be done
d> (*) How long that's expected to take
d> (*) What got done
d> (*) How long it actually took

d> with an eye towards being able to easily calculate velocity and such?

The latest one is not necessary to calculate velocity "and such". What is
the goal of collecting this metric?

BTW, I'm going to build web-app, supporting XP style of project management
anyway, since my case is little different from 'classic' XP. I have got a
remote customers (real , not XP) and they are _very_ keen on keeping track
on project progress.

--
Andrey V Khavryutchenko http://kds.com.ua/
Offshore Software Development http://www.kbi.kiev.ua/~akhavr

When something truly important needs to be said it often
makes people uncomfortable -- Roger Toennis
• ... The popular answer to this question is a 4x6 index card . ... How many stories are you going to complete in an iteration? Four? Five? Ten? To sum up 10
Message 3 of 8 , Jan 31, 2001
> So, I'm wondering... does anyone have any paper forms they use regularly?

The popular answer to this question is "a 4x6 index card".

> Something that lets them keep track of
>
> (*) What needs to be done
> (*) How long that's expected to take
> (*) What got done
> (*) How long it actually took
>
> with an eye towards being able to easily calculate velocity and such?

How many stories are you going to complete in an iteration? Four?
Five? Ten? To sum up 10 numbers (one off of each index card)
shouldn't take but a few minutes, at worst. IMHO, that's easy
enough to calculate velocity.

You write down a Story per card, break it up into tasks (if necessary)
on the same card, write estimates on the card ... then, say, on
the back write down who did what and when and how long they spent
doing it.

If you really need more space, staple two cards together. That
should be rare enough that you won't have many stapled cards to
really be bothered by it ...

They're lightweight (in both use and physically), ultra-portable,
inexpensive and easily obtainable ... and the learning curve is
really smooth. (Anyone who's challenged by using index cards
probably are the same people who actually need the explanation
of how to wear a seat-belt when you're sitting on an airplane...)

- Dossy

--
Dossy Shiobara mail: dossy@...
Panoptic Computer Network web: http://www.panoptic.com/
• ... Use no formulae. Just track Velocity. See the Velocity index entry in XPI or in PXP. Why is your lab notebook not structured enough? All you need for
Message 4 of 8 , Jan 31, 2001
At 10:22 AM 1/31/2001 -0700, it seemed like dbrady@... wrote:
>Question.
>
>I'm about to start playing the Planning Game in earnest, and I've discovered
>that my little lab notebook doesn't *quite* impose enough structure for what
>I need. I've tried using an Excel spreadsheet, but that's even worse. When
>I *do* remember to fire it up, I can never get the time formulae to work
>right.

Use no formulae. Just track Velocity. See the Velocity index entry in XPI
or in PXP.

Why is your lab notebook not structured enough? All you need for velocity
is story points done over time. All you need for task tracking is time-in,
time-to-go for each task. What happens if you track that and wait to see
what else you want to know?

How many programmers are there? A dozen will easily fit in a couple of
notebook pages.

>I've convinced my manager to let me play the planning game and track
>velocity as an experiment to see if my estimates and scheduling is/gets any
>better than the currently standard SASTW* model.
>
>* ShrugAndSayTwoWeeks
>
>I've heard several opinions on this group that writing time tracking
>software just isn't the way to go. It does strike me as not being the
>SimplestThingThatCouldPossiblyWork.
>
>So, I'm wondering... does anyone have any paper forms they use regularly?
>Something that lets them keep track of
>
>(*) What needs to be done
>(*) How long that's expected to take
>(*) What got done
>(*) How long it actually took
>
>with an eye towards being able to easily calculate velocity and such?

Again, velocity is not calculated, it is recorded. Velocity is the sum of
the estimates on the stories actually accomplished in the iteration. If you
that actually got done (but I'd only count them if the story was complete,
because it's so important to complete stories).

Completion is measured by acceptance tests, because of course you have
automated acceptance tests for all stories. (?)

If you are into serious complexity, write the task estimates and reals on
the back of the story cards.

Go simple, young man. Nothing else is worth doing until you can do the
simple thing.

Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
• We write our stories on index cards for Release Planning purposes and have a giant pin board where they get prioritized. For Iteration planning we use flip
Message 5 of 8 , Jan 31, 2001
We write our stories on index cards for Release Planning purposes and have a
giant pin board where they get prioritized. For Iteration planning we use
the task by putting their initials and time estimate along side the task
description. Estimates are done in relative degrees of difficulty, i.e. if a
similar task took 2 last time then we estimate it as 2 this time.

We know how many unit were successfully implemented last iteration and so
the business team simply pick the same amount of work for this iteration. We

Once the stories and tasks are assigned for the iteration we take the papers
off the flip charts and tape them up around the room. Once a task is
completed the owner checks it off...

The simplest thing that could possibly work... and it works very well.

On the last project that I coached we had a planning room that was dedicated
to the project and the walls were covered in white boards. We used those
instead of flipcharts. For historical (i hate saying CYA) purposes we would
take pictures of the walls with a digital camera.

Do you really *really* need some software to do this??

Gareth
• Outstanding. You win the Ron Jeffries Planning Game Award. Collect the next time we re both in the same bar. For use with digital cameras consider
Message 6 of 8 , Jan 31, 2001
Outstanding. You win the Ron Jeffries Planning Game Award. Collect the next
time we're both in the same bar.

For use with digital cameras consider www.pixid.com, the WhiteboardPhoto
product. Based on my use of it, it works as advertised.

Go, Gareth!

R

At 02:56 PM 1/31/2001 -0600, it seemed like Gareth Reeves wrote:
>We write our stories on index cards for Release Planning purposes and have a
>giant pin board where they get prioritized. For Iteration planning we use
>the task by putting their initials and time estimate along side the task
>description. Estimates are done in relative degrees of difficulty, i.e. if a
>similar task took 2 last time then we estimate it as 2 this time.
>
>We know how many unit were successfully implemented last iteration and so
>the business team simply pick the same amount of work for this iteration. We
>
>Once the stories and tasks are assigned for the iteration we take the papers
>off the flip charts and tape them up around the room. Once a task is
>completed the owner checks it off...
>
>The simplest thing that could possibly work... and it works very well.
>
>On the last project that I coached we had a planning room that was dedicated
>to the project and the walls were covered in white boards. We used those
>instead of flipcharts. For historical (i hate saying CYA) purposes we would
>take pictures of the walls with a digital camera.
>
>Do you really *really* need some software to do this??
>
>Gareth
>
>
>
>To Post a message, send it to: extremeprogramming@...
>
>To Unsubscribe, send a blank message to:
>extremeprogramming-unsubscribe@...
>

Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
• In my little shop of (4) programmers, we have one big white board showing the current iteration with story and task numbers. story task task task story task
Message 7 of 8 , Jan 31, 2001
In my little shop of (4) programmers, we have one big white board
showing the current iteration with story and task numbers.

story
story

Each task is half a day, unless otherwise noted. (3-6 hours is
allowed per task). We all figure out the tasks together, then the
person who signs up gets a chance to adjust (this works well because
we have a high concentration of less experienced developers who are
learning how to plan and estimate). Then I, as the tracker, get to
set up the dates.

Each task's target completion date with a half day granularity is
posted on the wall on an erasable 30 day calendar (each person has a
color) big as life. That is pretty much it for schedule tracking,
very low maintenance because everyone can see what is going on.

We also have an automated time tracking system that tracks stories,
but not tasks. This works OK for its purpose, which is to track
actual engineering hours. It has proven to be pretty much useless
for historical metrics, though. In trying to use the history for
preparing new estimates, and I ask "what stories have we done that
are similar to this one?" everyone gets all hung up on
what "similar" means. I am currently stuck in my own "function
point" oriented thought process on this topic and have not come up
with a good solution (i.e. one that can be done in a reasonable
amount of time by the developers themselves). Also, the experience
level (maybe my own) is probably playing a big role in this issue.

Our on time record has improved about 200% since we started planning
this way. This makes me VERY heppy. Before it was take-your-best-
guess-then-double-it-and-pray. The process of task oriented
estimating (simple but effective) has made all the difference. Being
able to map the task to a calendar within a day or so is such a huge
leap in status tracking, I will never work without a plan on this
level again.

The key is to keep it small. Trying to estimate 500 tasks this way
would certainly be a disaster, not to mention giving you a headache
from the smell of the erasable markers.
• ... Something in my brain makes it impossible to say no to beer... You re on. Gareth
Message 8 of 8 , Feb 1, 2001
> Outstanding. You win the Ron Jeffries Planning Game Award.
> Collect the next
> time we're both in the same bar.

Something in my brain makes it impossible to say no to beer... You're on.

Gareth
Your message has been successfully submitted and would be delivered to recipients shortly.