How to use story points to track velocity with VersionOne?

384 views
Skip to first unread message

Cat Schwamm

unread,
Oct 22, 2008, 11:32:06 AM10/22/08
to VersionOne-users
My development team has not taken well to having to constantly change
the ToDo Estimates and such whenever they work on a backlog item.
They would rather just drag and drop them to the proper status and be
done with them. This, however, ruins our reporting and I am, as such,
unable to track velocity. I would like to use story points to track
velocity instead, but do not know exactly how to do it. If I put the
point value as the ToDo Estimate, when the item is dropped into
Completed on the taskboard, will it show it as being completed (as far
as time goes)?

I would really like to have accurate reporting using VersionOne, but
without disrupting the workflow of the developers and forcing them to
do things that they hate. Any suggestions?

Thanks!

Cat

Kevin S.

unread,
Oct 23, 2008, 10:49:41 AM10/23/08
to VersionOne-users
Cat -

I'm trying to make sure I understand your post....

Your team is mostly using the Task Board instead of viewing the
backlog grids or My Home page.
Your team is not interested in tracking burndown at the task level in
hours.
Thus, burndown needs to be tracked in story points on the backlog
item itself.

Can you confirm this?

Typically the difference between story points and task hours is that
task can be partially completed (through to do) and show a trend
towards when you will be done. Story points are typically an all or
nothing credit. You don't get velocity credit for a story in progress
until it is DONE DONE. Is this true for your group?

I'm trying to understand your culture and team process better so we
can understand what you are intending to support with the reporting
from V1.

Also, who is the audience for this reporting... the team or upper
management? What are you going to use the reporting to primarily
communicate or bring focus to?

Kevin E. Schlabach
http://agile-commentary.blogspot.com/

Cat Schwamm

unread,
Oct 23, 2008, 2:16:17 PM10/23/08
to VersionOne-users
Kevin,

Thanks for your response. You are correct in your understanding; we
are interested in using points to measure velocity and not track or
estimate hours.

The audience is internal to the team, to better measure the capacity
of the team.

And no, credit is not given to a story until it is done done.

Thanks!

On Oct 23, 10:49 am, "Kevin S." <ksch...@gmail.com> wrote:
> Cat -
>
> I'm trying to make sure I understand your post....
>
> Your team is mostly using the Task Board instead of viewing the
> backlog grids or My Home page.
> Your team is not interested in tracking burndown at the task level in
> hours.
>    Thus, burndown needs to be tracked in story points on the backlog
> item itself.
>
> Can you confirm this?
>
> Typically the difference between story points and task hours is that
> task can be partially completed (through to do) and show a trend
> towards when you will be done.  Story points are typically an all or
> nothing credit.  You don't get velocity credit for a story in progress
> until it is DONE DONE.  Is this true for your group?
>
> I'm trying to understand your culture and team process better so we
> can understand what you are intending to support with the reporting
> from V1.
>
> Also, who is the audience for this reporting... the team or upper
> management?  What are you going to use the reporting to primarily
> communicate or bring focus to?
>
> Kevin E. Schlabachhttp://agile-commentary.blogspot.com/

Kevin S.

unread,
Oct 24, 2008, 10:37:33 AM10/24/08
to VersionOne-users
Cat-

Sounds like you have a mature Scrum/XP team on your hands... that's
great!

Continuing in my assumptions, you don't need to track velocity
throughout the sprint then... you only need to know velocity of past
sprints when doing planning for an upcoming sprint.

In a paper world as a scrum master, I would always tally the points on
the story index cards on the wall before every sprint review. It was
a "team trophy" and pride point (or a large trigger for retrospective
a discussion).

I would guess that there is a report in V1 to sum backlog item points
for stories in a sprint after it is closed. I don't know off-hand,
but it sounds like this is what you are looking for.

Report: For date range (or last # of sprints), show me the bar chart
for total points taken into sprint and subset that were completed.

Let us know if this is what you want. If so, one of us or a
VersionOne mentor may have the answer!

Maggie Bullington

unread,
Oct 24, 2008, 1:57:15 PM10/24/08
to versiono...@googlegroups.com
Tracking velocity by story points is the norm. You can use the velocity trend report (included inline in the sprint planning and tracking screens) to do this. I think you are actually not talking about velocity though (which is the measure of how many points you complete in a sprint) - I think you are talking about a backlog item point burndown. The traditional Scrum burndown is a task burndown, which uses the ToDo hours - this burndown is inline in the tracking pages and is part of the Sprint Dashboard. VersionOne does however give you the Backlog Item point burdown as well. In the reporting section, there is a report under Project/Release Reports called Burndown. This is basically a story (or backlog item) point burndown. You can set the sprint filter to your current sprint and get what you are looking for. *Note* the burndown for Backlog Items is "burned down" by Closing the Backlog Items - so you'll want to close them out as soon as they are finished in the sprint. There is another report called Estimate Trend (many people call this one a "burnup") which gives a similar view of the Backlog Items completed, but in bar chart form.
Hope that helps.
-Maggie

Jack Ukleja

unread,
Oct 23, 2008, 8:11:13 PM10/23/08
to versiono...@googlegroups.com
Hi there,

We have just installed V1 (quite impressed so far) and are still getting
our heads around some basics.

We have just imported 700 stories, and I can see duplicates.

What is the best way to remove duplicate stories?

Obviously I can just delete one of the duplicates - but is there a
better way?
Perhaps relate the duplicates stories to the surviving story?
Should I close the duplicates instead of delete?
Perhaps there is a merge duplicates action?
Any other tips?

Thanks,
Jack

Maggie Bullington

unread,
Oct 27, 2008, 11:31:33 AM10/27/08
to versiono...@googlegroups.com
If they genuinely are duplicates, it doesn't hurt to delete them.
-Maggie
Reply all
Reply to author
Forward
0 new messages