Agilesparks

Doubling velocity (story points done-done in each sprint) usually means we must improve several things:

a clearer definition of done

no [known] bugs escape the Sprint

Helicopter Managers – who step in too soon to rescue thereby depriving the team to think and solve problems together.

Absentee Managers – who would not step in at all irrespective of whether the team has all the necessary skills to tackle the problem.

If the team has sufficient skills to solve the problem then give them space else ask questions to help them get unstuck. This would help in building the skills eventually.

Has the team made changes that make a difference to them as a result of the retrospective?

Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?

For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).

Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.

deal hours first This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They're now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn't matter any more. If you're new to agile estimating, and you're having trouble coming to terms with Story Points try this first and then make the switch later.

Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).

Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong

Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.

A good guide to follow is 20% of the total number of items. So, in the case of 30 risks being prioritized, each voting team member would receive 6 votes to assign across the population of risks.

*Please note that I'm specifically talking about productivity. Velocity is a great tool for estimating and planning and I'm not trying to change that. It's just not a good measure of productivity.

rather than asking your business experts to measure business value after delivery (difficult!), have them estimate it beforehand. Every story (or feature--keep reading) gets an estimate before it's scheduled. At the end of each iteration, add up the value estimates for the stories you completed in that iteration. This is your "value velocity."

And rather than reflecting the hours programmers work, as cost velocity does, value velocity actually reflects productivity. Remember, productivity equals output/time. Value estimates are a much better indication of output than cost estimates are.