Should you trust those agile charts?

Most CTO’s and IT leaders have received the agile message by now.  Your staff tells you about agile and this “scrum” thing from your IT department and they say agile has taken over the development world.  They then show you all these pretty graphs with sprint burn down charts, cumulative flows, velocity over time, MVP (Minimum Viable Product) burn down charts, release burn up charts, etc.

Everything looks stellar, but when you start asking about how those charts are measured, it will often lead to one ambiguous destination: story points.  First, as a disclaimer, there are other units of measurement that are available to track progress including (but not restricted to): hours, ideal days, duration, T-shirt sizes, % stories/PBI’s complete and you could theoretically use bananas as a unit of measure, but it is not recommended.  Naturally, you must choose something to track progress.

Naturally, your research about story pointing results in a series of explanations and diverse opinions from sources like Mike Cohn of Mountain Goat software, Scrum Alliance, and even Wikipedia under scrum and planning poker. You hear that story points are a relative unit of measure and can vary from project to project and even from team to team.  If you are interested in measuring and tracking story points consistently, please read my “Story point normalization – what’s the point?” article. However, my aim for this blog is to answer two questions:

• “What work should be story pointed?”
• “Should I trust those charts?”

Not such easy questions as one may think.  This blogger has seen a myriad of responses and they rarely align between people unless clearly articulated in detail.  For the first question, my simple response is, “All work delivered by the development team.” Moreover, all stakeholders that contribute and review delivery progress must have a shared understanding of tracked work.

The three pillars for scrum delivery are transparency, inspection and adaption. Only through transparency can we have clear inspection and effective adaption.  What work should be story pointed to create transparency when showing those pretty charts?  In an ideal setting, all work that takes time to complete.  Take this table for example:

Michael Dougherty

The recommendation?  Expose all work in story points that are relevant to tracking progress and if they change, require action to correct.  As a start, point the first two groups and track the other activities to ensure they support the flow of user stories (i.e. the “delivery fuel”) and quality validation (i.e. “fit for release”).  Communicate to all involved in story pointing practices to ensure consistency in report building.  The best reports follow the CASH principle.

Reports are:

• Comparable – Measured over time to itself or to a clear goal
• Actionable – A change in report results lead to clear actions required
• Simple – Kept to only a small set of variables, otherwise it is too complicated to understand and react to
• Honest – The report does not hide information, skewing the truth in delivery

So back to the second question, “Should you trust those charts?” Yes, you can trust those reports under the CASH principle, but always inspect whether those reports are truly following this principle through inspection and adaption.

Note that based on your journey in agile maturity, tracking all work in story points become less and less relevant, so you can remove pointing for work as long as there are no negative side effects (i.e. missing releases, commitments, etc.)  The team frees that time in tracking story points to focus on core product development as trust builds from self-organized teams delivering quality products.  Your charts will transition into more cumulative flows and User Stories completed over time.  Be careful to stay conservative with changes since many lose track of their effectiveness and efficiency as the team may become complacent.

As leaders in your organization do not request, but demand reports that follow the CASH principle, so you have a clear representation of story points in your delivery portfolio.  Those “hidden story points” will end up impacting deadlines, missing commitments and causing teams to burn out, attempting to keep up with more than what they have really committed.