What is Velocity?

Velocity can be termed as the run rate of the team . Agile teams use this metric to measure how much work was done in a sprint so that we know how much more is left to actually make the reason.

Let take a simple example.

The team has ten stories whose total story point is 140. They pulled around 30 points of work this sprint. They finished 25 points. This 25 is their run rate.

With this the team and product owner can project how many more sprints are needed to finish the work.

We are assuming that the team is using story points here.

Some myths about velocity
1. Teams velocity keeps increasing over time.
2. A team having a better run rate is a better team
3. Since some team last year delivered at a certain velocity, this new team will also deliver at the same velocity
4 Velocity can be a predictable measure sprint after sprint even if we keep moving team members in and out.
I have seen many team members mindlessly argue over the effectiveness of velocity and end up wasting valuable time.

In fact in the beginning in 2005, as a developer, I would not see the point of such calculations. After a while, I got used to this and stopped worrying about such metrics and just focused on writing clean code.

Also, velocity as a measure only works well with teams that tend to practice Scrum and not as much with Kanban or XP teams.

Many scrum masters get into this coach mode with a single focus to help increase the velocity of the team. Instead, I would encourage ScrumMasters to look at completing the work they pulled min style, as well as help team and team members, identify waste in the system.

This metric is not as important as a number of automated unit test or number of production bug in the system.

Story point and their relation to complexity and uncertainity

This article on infoq talks about the story point and its relation to complexity or time. The argument seems to be it should be only related to effort and not complexity

When team members say Extra large for a story, generally it can mean one of the following.

a) I don’t have all the information needed and hence I think it is large ( This is not complexity or effort. This is the ambiguity or uncertainty. In this case, we cannot really base the size on Effort as effort can only come to play when the team member knows that he or she needs to do

b) I know all about the story but this is complex. This is a good case to say this is complexity or more so effort. Its going to take me 10 days to do it as an example.

Story sizing is all about the relative measure.

The real effort only comes to play when you work on a story. At times what is a small story becomes extra-large, the effort grows. So there should not be a correlation to time alone. If we did time alone then why do we have to do task breakdowns?

Estimate size and derive duration. This picture captures the intent.

What are different ways to size stories? Why do we do story points, not hours?

MIke Cohn talks a  lot about this in his book Agile Estimation and Planning. You can use any measure to size stories.

Teams use different sizing techniques:

T-Shirt Sizing

X Small, Small, Medium, Large , Xtra Large

or

Coffee Sizing

Small, Tall, Grande

You can pick any sizing technique. Make up one if needed.

This is mainly done as we as humans and as managers are better at abstract terms. If we use hours as a way to size stories,then the managers in the room have questions, teams dont immediately feel comfortable with hours.

Sizing keeps the planning meeting at a fast pace.

A general measure you can use  for T-Shirt sizing is how many days it take to complete a story

Small story –  1-3 days

Medium – 3- 5 days

Large – 5 – 7 days

X Large > 10 days

In order to convert a story size to a number, you can use either factorial, Fibonacci, or Squares.

Sizing Techniques

If in a sprint your team does two small stories and two mediums then your velocity is 9 * 2 + 4 * 2 = 26 ( if you are following the squares technique). Square is simple and works quite well.

Be Aggressive with Velocity

We asked a bunch of Agile experts what is their thought on velocity? Here is the question

Should we select a velocity conservatively based on history vs. setting an aggressive velocity to encourage more productivity?

Here is what we heard

First Person:

I am a firm believer that the velocity is set by the team (not
management, not Scrum Master) as a measure of how much value they are
able to deliver based on yesterday’s weather and the team’s
capacity/ability at the time.

It’s an easy trap for management to use velocity as a measure of
productivity and assume that if they increase it a little more each
sprint the team will deliver more with the same quality.   That is a
myth.  The team should demonstrate that the velocity is based on the
best we can do given our current capabilities and knowledge we have at
the time.  If there is an expectation that they should do more, the
discussion needs to change to impediments that are keeping the team from
delivering more value.  Taking the discussion this way will encourage
the looking for waste and inefficiencies that could be improved or
removed in order for the team to be able to deliver more.

Increasing velocity will not motivate.  If anything, it will cause the
opposite and that the team is being asked to do something they aren’t
able to do on their own and really commit to.  This causes frustration
and breaks down the trust/transparency between management and the team.

Second Person:

The bottom line…You spend something each iteration and that is a function of time, cost, scope, and quality.  Fixing time and cost and increasing scope is unreasonable.  Over time, more maintainable code, better domain knowledge, improved team competencies, and better infrastructures will increase velocity.  Most other attempts (except removing people from multiple projects) will usually spend quality. Quality is spent either by reducing product quality or the teams’ quality of life.  Overworking people can have short spikes of productivity (a week or two) but statistics show that people working 12 hours per day are no more productive than 8 hours per day within 3 months.

From a lean perspective, more items will increase waste.  Also, overloading teams causes an overpressure on the teams.  If this were a pipe, the pipe would burst (sending caustic chemicals into the environment with long-standing and expensive problems).  Unfortunately, people are much more adaptable than a pipe and so the indicators of emergent problems is harder to recognize until too late.

http://www.scrumalliance.org/articles/14-technical-debt-and-design-death

Third Person:
My suggestion (which has passed no orthodoxy test) is to stay close to
recent experience, and maybe set some reasonable stretch goals IF your
the team is building coherence and effectiveness as sprints go by, or are
coming back from a difficulty, or are enthused and excited, or some
situational impediments have been relieved, or they recognize a need to
push some for the sake of the customer relationship. I think you have to
be very sensitive to reading the team psychology – their relationships
with each other, with you, and with the customer. In any case, I think
the team would have to sign up for any stretch goal, rather than having
it imposed by you, or god forbid, by the customer.

Fourth Person:
We have found that signing-up for less lowers the pressure and raises the confidence then the team actually does more than the stretch goal that if attempted always works against you and you deliver less.

Fifth Person:
My experience with stretch goals has been that they have four fundamental flaws:

1) There’s no good way to represent them in Agile planning and tracking tools/data.  If you fully flesh them out with task estimates and plan estimates, then you’ve potentially wasted that planning time (if you don’t get to them), and you’ve distorted your burn-down graph.  In particular, this often leads to quality loss and short-cutting in the first few days of the Sprint as people see that the burndown slope isn’t converging to zero, but don’t realize why.

2) They cause stress and distress to the team.  “Everyone knows” that management half-expects the stretch goals to be met, and yet if we-the-team were confident of meeting them, they wouldn’t be stretch goals, they’d be part of our velocity!

3) They cause bad customer expectations and bad feelings between the development team and the customer.  In every Agile project, I’ve worked on, if we gave the customer a stretch goal, the customer inevitably asked at the end of the Sprint, “Well, why didn’t you get the stretch goal done as well?”  The answer, “Because it was a stretch goal”, while entirely accurate and fair, never seemed to satisfy them.

4) Stretch goals are redundant.  We have, at least in theory, a prioritized Product Backlog.  The ScrumMaster and the Product Owner should be collaborating on an ongoing basis to ensure that at least the top 20% of that backlog is current, ordered by priority, well-understood, and ready for inclusion into the next sprint’s Sprint Backlog.  Well, there’s your stretch goals, ready-made and already in priority order.  If you happen to finish a sprint early, at a sustainable pace, and with optimal quality standards (the only time you should ever be looking for a stretch goal at all), you can go directly to your Product Backlog, take the top-most item, and voila, you have a stretch goal.  Negotiating explicit stretch goals with the customer obscures this resource and increases customer confusion about the role of (and the importance of maintaining) the product backlog.

For these four reasons, I strongly oppose the use of stretch goals in Agile planning.  Agile already has better solutions to the problems that stretch goals nominally address, and these better solutions are far less likely to cause poor customer communication and team distress.

What is Velocity in a scrum team

= Number of total story points / One iteration

Velocity is a measurement of how much the team gets done in an iteration ( called Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is planned.

In Scrum, it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

Examples are 1, 2, 4, 8, 16

5, 10 15 and so on.

A story depending on its complexity is given certain story points. So if the team does 6 stories that are 8 story points that iteration, the team’s velocity is 48 story points.