Is the Scrum Master responsible to send reports?

Hi PG,

Anyone can do it, for it to be "any point" in time it should be reported daily, team should be self organizing.
Its a scrum "team" Dev-SM-PO so in theory as long as its logged by the team, then anyone could.
This is where burndown charts come in useful, PO tracks it but the team should log it and it should be transparent to stakeholders, so in this case your IT department.
To avoid sending it, you can just make any burndown shared with stakeholders, no need to send it.
They can look and see when ever they choose and crunch any data from it.
Its one less thing you have to do, so the team stay on track for the Sprint goal.

Monitoring Progress Toward a Goal
At any point in time, the total work remaining to reach a goal can be summed.
The Product Owner tracks this total work remaining at least every Sprint Review.
The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal.
This information is made transparent to all stakeholders.

Thank you Michael for your insight. I really appreciate it.

What it's blur for me is that if it's the responsibility of the entire team to report status, who decides how and who will do it? Also, my understanding was that tracking the burn down charts was responsibility of the development team, not the PO. Is there some source that clarifies this more? Unfortunately the scrum guide is not clear on this area.

Thanks for your feedback.
PG

> I was informed by The Development Team the
> IT department has asked them for a status
> report during the Sprint.

What information radiators does the team have in place, and how is the IT department currently making use of them?

We do use burn down charts, burn up charts, story boards. Mostly physical charts, so the ideal would be to have these radiators in an online platform to grant access to any external department to or stakeholders to see them at any point, correct?

My main question is: A) should the PO create this report and send it to the IT? B) The SM (me) should create this report and send it? Or C) Tell the DEV team to figure it our themselves?

It would be best to make these radiators available, either physically or electronically, so that stakeholders can see them without the need for reports. Reports are subject to filtering and delay and their production consumes time and effort.

It's also important to bear in mind that in agile practice, the proof of success lies in ongoing delivery and not in reporting. The interest of the IT department should be to facilitate incremental delivery and to assist in the removal of any organizational impediments. Blockages, risks, dependencies, and issues outside of a team's control should be flagged on information radiators so stakeholders can act accordingly.

Instead of expecting reports, the department should be pro-active in monitoring these radiators throughout each sprint, and in providing Scrum Masters with any support they may require.

Thank you Ian for your feedback. Let's put it this way: The organization request us to present a report, regardless we have those radiators. I also remember that in a question from the test it was this was addressed giving several options that the SM will do. If I remember well it was something like: A) ask the PO to send the report; B) The SM create it and send it; C) Tell the DT to fit the report into the Sprint Backlog.

If you would pick from these options, which ones is the best one?

The least worst of those options would be B. A can be eliminated on the grounds that the IT department is not a business stakeholder and so the PO would be unsuitable as a liaison. C can be eliminated because it is inappropriate to use the team's time for non-value adding purposes.

That leaves B, which is the "least worst" option because the SM would deal with the impediment. It still isn't a good option though, because what the SM *should* be doing is coaching the department to make better use of information radiators and to be more pro-active in supporting team delivery.

Thanks Ian. We are working on improving our information radiators in order to make the process easier for everybody and also bring transparency into our development.

What software/online applications do you recommend for us to look at?

> What software/online applications do you recommend for us to look at?

I don't. As a general rule I think it is best to defer the use of electronic boards and radiators until the correct organizational behaviors are in place.

I'd recommend using physical boards and charts to begin with, while coaching departmental stakeholders in "gemba" and related practices that support actual team delivery.

Thank you Ian for your insights and wisdom.
Yesterday I finally took the test for PSM I passed.

All the best!
Pablo

I'm fairly new to Scrum, and i'm still preparing myself to take the PSM 1, but i think i can add something useful to this conversation.
Well, based on what i read the PO is responsible for being the "Bridge" that connects the clients and stakeholders to the Development Team and the SM. Thinking like that, your organization is the stakeholder, so it should be the PO's responsability to convey information and produce/send reports.

Sorry for the late reply, and tell me Pablo; how was your PMI 1 certification? Was it too hard? I'm planning to d it myself next month.

Cheers

But the scrum master is responsible to teach scrum to the whole organization ;-)
Shouldn't it be useful if the SM provide some useful reports to convince the organization that "scrum works" ?

> Shouldn't it be useful if the SM provide some useful reports to convince
> the organization that "scrum works" ?

There can be certain tactical reasons for using reports, such as those which show the elimination of waste, or which capture important actionable metrics.

That aside, I'd be reluctant to demonstrate the utility of an agile method on the basis of reports. It's delivery that counts.

Hi Ian,

Below is the full question:

The Development Team informs the Scrum Master that the IT manager has asked for a status report during the Sprint. The Scrum Master will:

Bookmark this question
A) Ask the Product Owner to send the manager the report.
B) Create and deliver the report to the manager herself.
C) Tell the Development Team to fit the report into the Sprint Backlog.
D) Tell the Development Team to figure it out themselves.
E) Talk to the IT manager and explain that progress in Scrum comes from inspecting an Increment at the Sprint Review.

To me the correct answer is E, how do you think?

If an IT manager was to ask for a status report during a Sprint, then E would be the wisest approach.

Thx Ian.
Hope that you don't mind if I ask another question.

What is the accountability of Product Owner during Sprint 0?
a. Make sure enough Product Backlog items are refined to fill the first 3 sprints.
b. Gathering, eliciting, and analyzing the requirements that will be inserted into the Product Backlog.
c. There is no such thing as Sprint 0.
d. Determine the composition of the Development Team so they have capacity to deliver the completed forecast.
e. Make the complete project plan to commit day, budget, and scope to the stakeholders.

a is something a bit correct to me but I don't like the "first 3 sprints".
b to me is a correct answer.
c is incorrect to me since during searching about scrum, I did saw something related to Sprint 0.
d and e is incorrect.
How do you think?

> c is incorrect to me since during searching
> about scrum, I did saw something related to Sprint 0. 

Have you ever seen a "Sprint 0" mentioned in the Scrum Guide?

What did the material you read have to say about "Sprint 0"? Was it a real Sprint which delivered a product increment, and which was timeboxed the same way as other sprints? Did it support inspection and adaptation with Scrum events? Or was it a term applied to setup and initialization work before actual sprinting begins?

Below is one of the link I've searched:
http://amitsinghmalik.blogspot.com/2013/03/sprint-zero-activities.html

Yes, you're right that Scrum Guide mentioned nothing about Sprint 0.
Correct answer should be C.

So normally, what do we already have before the first sprint?
- A requirement that can be put into Product Backlog?
- Formed team with PO/Scrum Master/Development Team?
- Necessary resource?

With them we can start the first sprint as a normal sprint by a sprint planning, and maybe backlog refinement can be also included in this first meeting too?

The only essential pre-condition to the first Sprint is a modicum of ability to engage in Sprint Planning. Planning implies that the associated responsibilities of each Scrum role can be satisfied and that there is work to plan. However, these essential matters could potentially be resolved *during* planning, and they do not therefore represent preconditions for entry.

In this context, I would try to make everything as transparent as possible (reporting tool) and ask the questions of why they need the report and how they would be using it.

I think the important distinction here is that SCRUM is a development methodology and not a project management methodology. Projects include many aspects that are not development and that SCRUM does not and should not address. As will SDLC, iterative development and other agile methodologies, they only address development, they don't address organizational change management, vendor management, communication management (for the project), risk management (for the project) , etc. SCRUM can be used in the context of a project or for ongoing development of a system. Projects have defined start and end points. A scrum team can be in place as long as the system they are developing exists.

I think the SCRUM team should do what it does and a Project or Program manager should handle all external reporting and communication. The needs of high-level stakeholders will never be served by any radiator that is useful to a SCRUM team. Their needs are high-level and strategic. They need to know if the project is on budget (budgets still matter), on time , meeting expectations, accomplishing the goals of the project, etc. No SCRUM radiator contains that information. SCRUM radiators can tell you how development is going, that's it. They say nothing about how prepared the organization is for the change, whether more time or investment is needed, etc.

I think this question addresses an important distinction, SCRUM is a development methodology and NOT a project management methodology. SCRUM can be used on a development project, but it also can be used for ongoing project improvement outside the context of a project.

The SCRUM team should do what it does and should not be saddled with project management or functional management duties. If central IT needs information, it likely is not anything that an information radiator can provide. They are likely more interested in project or program level information that should be provided by a project manager, program manager or functional leader. SCRUM should not try to 'tack-on' additional functions outside of development that would only bloat and complicate an effective, focused and efficient development methodology.