Author Archive

Value AND Velocity!

November 13, 2009 · Filed under Point2 - Process and People · Tagged , , , ,

In last week’s post I talked about how a stakeholder can use Value Points as a useful metric, and how to assign Value Points to epics.  Value Points are good for determining whether the team is working on the right projects but they don’t paint the entire picture.  This is where Velocity points come in.

At Point2, we estimate story sizes based on relative complexity.  The simplest thing we can do is a 1, something about twice as difficult a 2, and so on.  Some people prefer time estimates, either method of sizing stories is fine here.

Once you have both Value and Size estimates for your stories, you can plot them on a scatter plot.  Here I plotted story size on the X axis, and Value on the Y axis.  Small size, high value stories are in the upper left quadrant, low value, large size stories are in the lower right.  In this example, I would probably get the team to do all but 3 of these stories, those being the ones with size 5, value 2 and 3, and size 3, value 1.

scatterplot

The interaction between value and size is an excellent way to make sure your team is delivering the right product.  High value, low complexity stories are great for delivering some quick value, possibly as a means of generating the capital to tackle the larger projects.  Low value, high complexity stories might be best left on the shelf, or alternate means of solving the problem sought.

By: Tefon Obchansky

Leave a comment »

Value as an Agile Metric

November 5, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , ,

At Agile 2009 I attended Brandon Carlson’s talk entitled “Value or Velocity?“.  Velocity is often thought of as a measure of speed or productivity, but if a team can deliver x story points’ worth of the wrong product, and another team can deliver the same number of story points’ worth of an amazing product that everyone wants, but the two teams are said to have been equally productive based solely on their Velocity numbers.

In other words, getting more done is meaningless unless you know you’re getting the right things done.  To make sure you’re doing the right things, Brandon suggested assigning value points to epics.

The simplest method is Value Poker, kind of like Planning Poker.  The Product Owner assigns a value to each epic relative to other epics in the sprint backlog, with the smallest amount of value being a “1″, just like the story that requires the smallest amount of effort is a “1″ in Planning Poker.

Another, probably more accurate method is Attribute-Driven value assignment.  In this case, all product owners and stakeholders meet and assign values to epics together.  Each stakeholder will know the most about one or a small handful of attributes.  Some possible attributes include: market differentiation, strategic alignment, usability, system stability, sales commitment.  Draw up a chart with each attribute as a column, and each epic as a row.  The stakeholders for each attribute assign a value of 0-3 in each row for how valuable the epic is for that attribute.  Total up all the values for a row and then you have numbers you can sort on, and that can become your prioritized list,

To a stakeholder it is much more meaningful to hear “this month the team delivered 31 value points” as opposed to “this month the team delivered 31 story points”, because at the end of the day it’s delivered value that customers pay for, not complexity of stories.

By: Tefon Obchansky

Comments (3) »

Blitz Planning at Point2

September 8, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , ,

One session that I attended in Chicago at Agile 2009, and thoroughly enjoyed, was Alistair Cockburn’s Blitz Planning workshop.  First, Alistair is an engaging speaker and is full of great ideas.  Second, it was the last day of the conference and I was eager to start trying some of these new tricks, tips and techniques I’ve learned about all week at home at Point2.

Blitz Planning results in “getting the contents of everyone’s head into a common space” and is meant to be speedy.  In the 90-minute workshop we planned a non-technical workflow (the process of getting up in the morning and getting out the door), then we planned an information kiosk system start-to-finish, and identified the earliest we could do the initial rollout.

blitzplanning1

Ideas are recorded on index cards by all members of the team as they come to mind and are not subject to scrutiny by other team members.  As a team member writes on a card, they call out their idea to help avoid duplication, and to spark more ideas from other team members.  When the team feels the plan is near complete, the cards are laid out on a table in chronological order, the plan is checked for completeness and any dependencies are identified.  At this time cards may be torn up, and more cards may be written to fill the holes in the plan or re-work it to remove dependencies and shorten the critical path to allow early delivery.  Alistair introduced the concepts of the “technical walking skeleton” and the “business walking skeleton” which contain the bare minimum to make it work, and the bare minimum to provide business value, respectively.  Your earliest possible delivery consists of both the technical and the business walking skeletons.

Unlike the information kiosk example at the conference, the project we planned touches existing systems and contains many moving parts.  Instead of 20-30 minutes to design a system and discuss it, we took an afternoon to write the cards and discuss, and we have more discussions and card-shuffling sessions planned for the next few days.  So far it’s been an interesting exercise and I feel like we’ve identified several potential problems early.  I’ll keep you posted.

By: Tefon Obchansky

Comments (2) »