Jeff Sutherland and Jens Østergaard visited the Sydney Scrum Meetup last Thursday. We had some great pizza and then they got everyone doing the Nokia test!
My Test Results
Iteration length, 2 weeks – 10
Testing, customer acceptance testing – 8
Agile specifications, poor user stories – 4 (good enabling specifications might be 3-5 pages long – before sprint planning)
(for venture companies Jeff finds that 2 sprints planned is necessary)
Product owner, product owner with backlog – 5 (or 2 with last project!)
Product backlog, single product backlog - 3
Estimates, backlog estimated by BA – 0
(Jeff said that usually as teams get better their stories get smaller and eventually are about the size of tasks, and then estimating changes to use points vs hours – surprising what can be untangled and done separately)
Sprint burndown chart, no chart, but team knows velocity – 0 + 3 + 2
(Jeff mentioned that partial completion of tasks creates a high-risk environment)
Team disruption, project leaders telling people what to do – 3
(self-organise to maximise velocity)
Team, no emergent leadership - 1
Total = 4.33
Most of the room were between 2 and 5, and apparently, most of OpenView’s venture companies start out around 4, but when they work on it they end up around 6. It looks like TIDC might have a great Scrum team as someone from there scored 8 for their team! (they were the only one higher than 5)
If your reference stories change then so do the story points. But Jeff said it is really the delta in velocity that is interesting. One of the symptoms of hyper-productive teams is that you get asked to slow down!
- Sustainable pace
- Quality
- Velocity
- “Balanced Scorecard” (not right term, but Jeff couldn’t remember what it was)
Jens recommends the XP game for teams to learn about velocity.
How long does it take to fix a bug from CI/automated testing. If longer than 2 hours then create an impediment list and get the Scrum master to remove them. Simple metric, track the day you start a story and the day you finish a story and then compare to your standard process efficiency (usually around 20% – measures the quality of your backlog) {calc elapsed days versus theoretical ideal days based on velocity}. Raising the efficiency meant getting the backlog well enough detailed that you spend less time waiting to do a particular item. Measuring the time to Done.
Speed of testing is usually the bottleneck, and is more important than the speed of coding. So interrupt devs immediately with a bug, rather than leaving them to finish what they’re doing. The availability of testable code is another way of thinking of it.
Just evaluate the code in production is one way of incentivising people.
I asked about how to handle client projects using Scrum, Jeff mentioned that Systematic is doing big fixed price contracts using Scrum. They provide 2 bids on every project, with the Scrum bid at around half the price.
In response to someone’s question about Scrum, Jeff mentioned he’d written about the answer in an article titled Future of Scrum from the Agile 2005 conference.
Metrics to Live By
Jeff got me hooked on metrics as it is obvious when talking to him that empirical process control requires metrics to be successful. Some of these metrics assume that you use story points for estimating, which we have done with some success on one project. To do this well you need a range of reference stories of various sizes and rough sizing (e.g. Fibonacci numbers) that the team can agree on the size of.
Here are some of the metrics Jeff mentioned:
Backlog Velocity = story points/sprint
Sprint Velocity = story points ‘done’/day
Efficiency = story’s ideal days/actual elapsed days from ‘start’ to ‘done’
(if an item should have taken 2 ideal days, but it actually took 10 days from the ‘start’ to the ‘done’ date, then you have 20% efficiency)
Churn = % of ‘done’ items that testers send back to developers for fixing
(if all items churns once then you have 100% churn, if half of those churn again then you have 150% churn! Ignore size of item when calculating)
Jeff has an upcoming conference session on this very topic and he discusses it further in his Excel Spreadsheet for Hyperproductive Scrum Teams post. The spreadsheet seems a little hard to get into, but I’ve given it to our Solutions team to review.
