Due to the fact it was holiday season we had a small but enthusiastic group and the conversation took many interesting twists and turns.
The Product Owner needs to be seen to be delivering value for money. Agile is not a blank cheque and we need to justify what and why we are delivering. It is necessary to measure progress and enable early identification of issues.
Velocity seemed to be a popular metric (Story Points per Sprint). However it can be problematic in that initially it has to be an estimate and Project Managers can get rather twitchy. Once the Team has a few Sprints under their belt and an average velocity is available then it’s much more useful to both the team for Sprint Planning and for the Product Owner in giving a view of when the backlog could be potentially completed much longer – however it’s still just an estimate and will be constantly refined.
Reclaim the Estimate
The group put forward that the word “Estimate” tends to be regarded in the same way as a “Fixed Price Estimate” ie the price you are expecting to pay. It was suggested a better term might be “Forecast”.
How Much to Estimate?
As an interesting aside CA Technologies (formerly Rally) recently produced a survey that showed that in terms of performance “Lightweight Scrum” (Story Points only) was best , followed by “Full Scrum” (Story Points and Task Hours), then “No Estimates” and finally “Hour-Oriented” (Task Hours only).
The survey is available here: http://www.projectmanagement.com/pdf/469163_the-impact-of-agile-quantified.pdf
(See also #NoEstimates)
An interesting example of estimating Tasks is rather than down to Hours is to estimate tasks in Half Days, as the it’s easier to think of finishing something this morning or by the end of the day – rather than I have x hours left to complete.
What to Report
In the Agile Manifesto we value “Working software over comprehensive documentation” and this can be used to try and fob requests for documentation (and other metrics) off. We discussed that the Agile Manifesto also acknowledges “there is value in the items on the right”. So we need to ensure we have the Appropriate Level of Documentation and this needs to be determined up front so the Dev Team can account for it.
Any reporting needs to have value in that it is useful for the audience – if there is a need for Gannt Charts we needs to deliver them.
The group briefly touched on who should provide the metrics? ScrumMaster seemed the obvious supplier but it was put forward that the ScrumMaster is a coaching and facilitating role and should it not be the Team delivering the metrics to the Product Owner who can then create the documentation for their audience. In reality it seemed that the ScrumMaster often provides any reports as needed.
And that was not all!
As well as the topic picked (and we never managed to get to the second as the group was in full flow) we also touched on
Discovery Phase – It is Valid as you only start Sprinting when you are ready.
Multi Skilled Teams – A title is your specialisation not your job.
Project Managers – Is a better term Delivery Managers?
Pair Programming – when training the learner should be doing the typing – muscle memory.
All in all it was a very enjoyable and intense session and I’m looking forward to the next one on September the 6th!