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.
MoSCoW rule
Agile Practitioners Guide 