Creating a weekly report as a Scrum Master

Last post 01:13 pm January 14, 2020
by Jon Bartek
8 replies
Author
Messages
03:29 pm January 10, 2020

Like the Volatility, percentage of stories accepted so far and the likes. What tool is applicable?

05:15 pm January 10, 2020

I'll start this off.

Why are you creating a weekly report? Who is the consumer of the report? Why is there a need for a weekly report?

As a Scrum Master I have never created a weekly report. I have never created any kind of a report, especially on a specific cadence.  There should be no need for these reports if the Scrum Team is radiating information correctly and if the organization as a whole understands where to find it and how to interpret it. 

As for what tool?  There is no applicable tool.  There are a lot of tools that are usable for creating reports but the application is entirely dependent on the situation. I don't have enough information to provide you with any suggestions so if you can provide more details in what you are trying to achieve and why, I am sure you will get much better suggestions. 

07:25 pm January 10, 2020

The Scrum Master is much different from a traditional project manager (who creates weekly reports). The Scrum Master should help whoever is asking for such information understand there are better ways and perhaps a better place and time; in fact there's a Scrum event for sharing information: the Sprint Review.  And at the Sprint Review relevant information is shared by those accountable. Might sharing data such as value delivered rather than % of stories completed be more meaningful? 

08:52 pm January 10, 2020

Why?

Reports aren't always useless, but of course... "Working software over comprehensive documentation". 

The others have good points, but nothing says a Scrum Master cannot do this task, simply the Scrum Team is self organizing.

There may be value in reports. If there is, sometimes self-created tools are best. But needing reports may be a symptom of something else. Perhaps there is a gap in transparency? I do not know without context.

Optimize for the team/product as that is the goal, not tools or leadership. Where you optimize in one place, you de-optimize in another.

 

10:24 pm January 11, 2020

@ Margret - You can consider JIRA as a tool to satisfy your specific reporting requirement. 

06:11 am January 12, 2020

You could also just use Excel. It'll be easier to work with. There are a few Agile management tools but in my opinion they make things more complicated.

05:37 am January 13, 2020

@margaret, correct me if I am wrong, is this report for management? 

As for percentage of stories accepted and likes -> so If you had the data that 60% of stories are accepted, what is next? same on when you found that 50% of the stories, the team likes it, why is this relevant?

We do not need that data to improve on stories, this needs to be phrased correctly and raised by the team itself on the different scrum ceremonies. Are the stories not clear enough or stories are too big.

05:57 pm January 13, 2020

To add to what Sherwin said, reporting/metrics are really only valid and worth measuring if there are actions that can be taken based on such measurements.

Volatility?   % of items accepted?   What is the target range for these measurements, and why?   What actions might be taken if such measurements fall outside of such target ranges?

If such measurements/reporting are being done without inspecting and adapting, I would question the validity of such reporting.   

Remember that the 10th Agile Principle is "Simplicity--the art of maximizing the amount of work not done--is essential."   Eliminate those activities that do not produce value.

01:13 pm January 14, 2020

I agree with Tim Baffa above. Reporting metrics and measurements is fine but make sure you have an Agile-related action afterwards. 

i.e. Help the team estimate better, help the team select stories for the upcoming sprint better, stronger sprint goals, etc.