minimum scrum reporting requirements iyo

[dotnetguy]

Hello, what do you consider the minimum reporting requirements for a Scrum reporting tool? I think the following fields are needed at a minimum:

* Team Member
* Epic ID
* Epic Name
* Story ID
* Story Name
* Step Number
* Step Name
* Is Blocked
* Notes
* Hours Spent
* Hours Remaining

The Step field would represent the step in the workflow like Started, Ready for QA, etc.

[Howard Sublett]

Andrew,

It sounds like you are trying to set a global standard- and your suggested minimum would then be far off base.

If a index card represented a story of work needing to be done, and it said : "elephant lump " and the team members/PO knew clearly what work needed to be done, and it was moved to done with no annotation on a physical wall- it would be a acceptable minimum.




Howard Sublett
Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
> To post to this group, send email to scruma...@googlegroups.com.
> Visit this group at http://groups.google.com/group/scrumalliance.
> For more options, visit https://groups.google.com/d/optout.

[Wouter Lagerweij]

What does the tool report on? What is the goal for the report?

Why is the team member important in any report? 

Why would any hours be important anywhere?

Why would you report on step number? And why are they numbered anyway?

Wouter

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Wouter Lagerweij          | wou...@lagerweij.com

http://www.lagerweij.com  | @wouterla

linkedin.com/in/lagerweij | +31(0)6 28553506

[Dan Rawsthorne]

Scrum doesn't require much.

I would say the following are necessary:
 - Story Description
 - Story State (not Ready, Ready, not started, in progress, Done)
The following may be useful:
 - Parent Epic Name

IMHO, anything else is about the organization's need for info, not scrum.

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Leonhard Grugl]

I totally agree with your questions, especially the first two of them. Hope you don't mind if I ask them again a bit differently:

What kind of information shall be reported to whom and why?

This topic already jump starts right into my argumentation against (such) tools: They often try to define a standard, which can hardly ever exactly meet a certain organization's requirements. So, many of them choose the approach to define the common maximum, which then leads to a huge, but worthless reporting effort! Scrum does it right by not defining any reporting standards, since it is so dependent on organizations, projects, communication levels, etc.

In my team - and I wish I could talk for larger parts of our organization -, the reporting from the bottom of the development process is kept to the very basic information, which has already been mentioned: a physical task board, showing stories and tasks in their states Due, WIP and Done. We have task cards, although stories many times would be sufficient. Tasks come in handy for stories which can be worked on by several people, since they resemble the information we gathered during planning about which individual tasks need to be done for the story. Mainly for later reference when technical questions come up, I (as Scrum Master) do note the names to tasks in an electronic list. That list is also the source from which I make a burndown chart, containing open tasks and story points (I do question that chart, since I don't find it very useful, but the rest of the team wants to keep it). Also, we note on the cards, when a task was started and how many calender days it has been worked on. Yes, calender days, not hours spent! We do that only to see if a task "stalls" and probably help is needed (e.g. started 4 days before, but only 1 day been worked on). At the end of a sprint, we also do a short re-assessment of the stories to see, if our estimation was correct. This should some day help us better defining our velocity, but I haven't yet found the time to analyse it.

After all, the sprint backlogs, re-assessed stories, protocols on who worked on which task and finally the story status (done?), I consider the essentials to keep the process up and running. Additionally, I have the total hours spent on the project by person from the mandatory time tracking system. Luckily, having all that at hand at any time, I could easily answer all management questions which came up so far. Of course, they can't look into a fancy cockpit and find a lot of information ready to be messed up by their interpretation, but would need to ask and talk with our team - but that's a good thing!

Right now, we're just before introducing Jira in our project (needed due to other stakeholders). Hope it works out...

[Nigel Baker]

The "Scrum reporting tool" is called Product Owner.

Everything else is collaborative techniques to assist with planning. 

Nigel 

[Wouter Lagerweij]

Hi Leonhard, 

Thanks for that!

My approach for reporting is definitely rooted in 'do the absolute minimum required'. That does result in rather wildly different results in different circumstances.

Most of the things you describe for your team, I would normally still try to avoid, as I think it takes too much effort and doesn't give additional work without adding value. Usually, within a team, all I need is the taskboard, and perhaps a tally of stories done per sprint.

Then if there are quality issues, I could add a tally of the number of production issues that occurred during the sprint that interrupted the team. 

But in other situations, I've done careful tracking of the cycle time of individual stories in kanban approach, using statistical analysis in a tracking tool to determine the lead times for items in different classes of service. And at that point, that was very useful information. I've also dropped that tracking at a later stage, when it was no longer adding value.

Wouter

[Derek GMail]

Scrum *requires* none of these. It mentions only that product backlog items benefit from having a description, order, value and estimate. There is no such thing as an epic, story, or step, in scrum. Ergo, the question you are asking does not relate to a 'Scrum reporting tool'.

--
Derek Davidson