Process Efficiency in Scrum - Why it Matters and How to Measure it

Update: See Process Efficiency – Adapting Flow to the Agile Improvement Effort the first of several papers to be published. By definition, Lean means that process efficiency is greater than 25%. The name Scrum derives from watching lean hardware teams. A new team can drive process efficiency to 80% in three days by implementing the Swarming pattern. There will be an iPhone and Android app available soon that will connect to Jira and display a Scrum team's average process efficiency per story.

The process efficiency of executing a story on a Scrum team is the most important metric for team performance, because a team can easily double velocity in one sprint by driving process efficiency up over 50%. A team from India asked me what KPIs they should use and I told them just use process efficiency. They drove it to 80% within three days and on the fourth day had completed all work for a two-week sprint.

This phenomenon has been documented previously in an IEEE paper Scrum and CMMI - Going from Good to Great: Are You Ready Ready to Be Done Done C. Jakobsen and J. Sutherland, in Agile 2009, Chicago, 2009.

Process efficiency is defined as the real work time divided by the calendar time to get to done. The required data is easily available in any Scrum tooling. What we want to see is average process efficiency for stories completed in a sprint in real time. We want to abandon hours as a reporting tool for Scrum teams as data on over 60,000 teams in a Rally survey shows that the slowest teams use hours. The fastest teams use small stories, no tasking, and no hourly estimation. How can we estimate process efficiency for these teams?

Here is a simple way to calculate process efficiency for one story. If the velocity of the team is 50 and the story is 5 points then the real work time for the story can be estimated to be 5/50 of a sprint. If the story is started at the beginning of the sprint and finished at the end of the one week sprint then it uses 5 days of a 5-day sprint or 1 sprint. If we divide 5/50 by 1 we get 10%. Make that number more than 50% and you will double velocity.

Our Webside Scrum team is implementing this for our company and there are a few questions that come up:

1. Do we just count business work periods in the denominator? What about weekends?
2. We use an interrupt buffer? How do we handle interrupts.
3. Webside process efficiency is over 100% because we have lots of small stories that get implemented really fast. Should we use a weighted average so that larger stories count more?

As we implement this I will update the blog on our approach. Even discussing how to implement a process efficiency metric has caused my Scrum team to introduce more discipline into backlog management and execution of stories.

In order for a team to improve process efficiency, they will have to stop multi-tasking and execute the Swarming: One-Piece Continuous Flow pattern. This is well known to radically increase the flow of story completion and is fundamental to lean production at Toyota.

Recently I met with Frank Verbruggen who is working on a Ph.D. thesis on the process efficiency of Agile teams. He wrote a nice blog on the topic after our meeting and we published a paper in the IEEE Digital Library:

Process Efficiency – Adapting Flow to the Agile Improvement Effort