# Queries in Agile process

How to determine the story point value in Agile methodology and determine the team velocity? In web search able to get the definition but not the actually process explanation.

-
The answers to this question on the Project Management SE may begin to offer some insight: pm.stackexchange.com/questions/4212/… – jcmeloni Feb 1 '12 at 1:58
You might be interested in a number of questions here about estimating story points, agile estimation, a definition of story points, and measuring progress in agile. – Thomas Owens Feb 1 '12 at 2:14

There's no "formula" for story points (and no "right" answer either). Think of story points as measuring the height of a building while standing far away. You may not be able to precisely determine the height, but you can estimate how tall it is relative to other buildings or structures. The same applies with story points. Come up with some baseline for "one point" and measure everything else relative to that.

There are various methods for determining story points, but the one I prefer is "planning poker." Buy (or make) notecards that have the numbers 1, 2, 3, 5, 8, 13, 20, and 40 on them (read here to see why). Each team member votes on the "size" of a feature be showing the card that is closest to the size they think the feature is. The high and low estimates explain their positions to the team (for expediency you can have one automatic re-vote without discussion) and the team votes again, repeating until there is consensus. Other cards that can optionally be included are 0, 1/2, 100, "infinity", and "?" (meaning unsure). There are pros and cons to using those sizes that are discussed in more detail elsewhere.

Velocity, on the other hand, is more scientific. It is simply the average number of points that a team _completes**_ in a given iteration. There is some variety in how you measure it (average all iterations? Just the mast N? Give more weight to recent iterations?) but if you keep the story point scale and the team members consistent it should give you a rough indication of how much the team can commit to completing in an iteration.

In the end, however, I encourage teams to do a "gut check" after defining an iteration. The team needs to commit to a body of work in an iteration, which may require cutting features if it feels like too much, or adding some if there is a high confidence that there is room to take on more.

** I define Done as a feature is fully coded, tested, and validated. I do not give partial credit for coding "most" of a feature (more specifically for completing most of the tasks necessary to complete a feature). I will count a feature if it has been coded but some bugs are found in testing, but will, of course, put those bugs in the following iteration and count the story points there

-

Story points represent a relative size. The actual figure doesn't matter. Comparing two stories you can estimate whether the two are the same 'size' or whether they are different in 'size'. Size here means a mix of effort, duration, complexity, risk, novelty and many more. It doesn't really matter.

To determine the relative size it pays off to do this as a team using "planning poker". Some teams use cards but basically it means that everybody puts their estimate on the table at the same time. If all agree, that's the estimated 'size'. If there is a large variation have the team discuss why they think it is larger or smaller. Then estimate again. Repeat until you have an agreement for each story. There are stories that need further exploration. Turn them into spikes with up to 3 days each. Then get together and see what you have learned from the spike.

For your first iteration look at the pile of prioritized stories and start from the top. Pick as many as you believe can complete as a team in that iteration. If you run out of stories before the end of the iteration pull in further stories. If at the end of the iteration stories are incomplete don't worry. Before you start your next iteration look at the total of story points that you completed. Don't pick more story points for your next iteration. Velocity is the average amount of story points you can complete. Some teams just use the average of the last four iterations. Be aware that this average can change. This is not a bad thing.

There are a few dangers that you'd like to avoid. Stay away from sizing stories too small, e.g. giving them smaller numbers than they are. Stay away from signing up for more story points than you can handle. It's better to pull in additional stories than to have incomplete stories at the end of the iteration. Stay away from imposing a story point number on a particular team. All they will do is put higher point values on stories. This is not an indication of increased productivity. Story points don't help with measuring productivity. They are planning tool for future iterations. Nothing more. Also try to stay away from splitting stories along traditional function, e.g. implement feature, test feature, integrate feature, each with their separate story. One story includes all work required to complete the story, coding, testing, integration, etc.

That should cover the basics. You'll find out that there are a lot of additional aspects and scenarios that are worth considering. Experience comes with practice. Just give it a try and learn from what works and what doesn't. Good luck!

-
+1 for warning against associating velocity with productivity. – D Stanley Feb 1 '12 at 3:50

Both @John and @D Stanley's answers are excellent, although you should note that "Planning Poker" is not essential to estimating using user stories. It is just a good way to bring the team to a consensus on valuations.

For the full scoop on User Stories, Mike Cohn's excellent book User Stories Applied: For Agile Software Development is the place to go.

-