How to measure productivity in Agile teams ?

No, the answer is not story points. Mike Cohn describes the answer to be cycle time.

A lot of people have written similar articles but I always end up finding people in the senior leadership who want to measure productivity using  story points. And there are those who want to compare one team's story points against another. And there are those who try to add story points across all teams without considering them to be different at all.

Reasons why people are so tempted to use story points are because

• They are so readily available to measure, that people don't feel like looking anywhere else. A
• A lot of Agile coaches end up not understanding cycle time well, 
• A lot of project management tools that claim to be "agile" do not support cycle time calculation at every level well enough.

I have seen "measuring productivity" conversations start when programs are behind schedule , senior leadership does not trust the teams or vendors , i.e. in general when the going gets tough. This is exactly the tipping point when a wrong measurement /KPI  can push the program into a completely wrong direction.

The scenario when "story points" are chosen as a performance indicator

• Will immediately lead to teams inflating their story estimates to look good on reports. 
• This will lead to a false perception of progress overall. 
• Teams could get completely demotivated as the focus moves to story points than actual working software as a measure of progress. 
• There could also be scenarios where quality is compromised for speed and a lot of defects creep in.

The scenario when "cycle time" is chosen as a performance indicator

• Will lead teams to think about how to measure it in first place. 
• It will lead teams to break the end-to-end cycle time into time taken from moving a story from Analysis to Development, from Development to QA, and QA to Done etc...
• Teams will end up thinking about definition of done / acceptance policy for each stage. And if a story moves from Analysis to Development violating the definition of done policy, the story is sent back to Analysis, providing immediate feedback to the previous stage owners to produce better quality work. 
• Quality then gets built implicitly into the process because of faster feedback and being able to fail fast, which are the fundamentals of an Agile team.

So choose your measures wisely :-)