In the first two articles of the series “What the Scrum Guide says NOTHING about”, our colleague Andreas has analysed “Definition of Ready” as well as „Estimations and Story Points” in the second article of the series.                                                                                                                                                                                                                                                                                                                                         It is also interesting that reporting, forecasting and status meetings are not described further in the Scrum Guide. Unfortunately, they do not have a particularly good reputation, as they are often seen as time-consuming administrative tasks. Nevertheless, our colleague Andreas sees a lot of potential in them. Find out here how they contribute to the three important pillars of Scrum and how they can be designed and implemented successfully and sensibly in practice. Enjoy reading!

Reportings, Forecasting & Status Meetings

… are also not mentioned in the Scrum Guide. As the Scrum Guide describes at the beginning, it is deliberately incomplete in order to give other (meaningful & goal-oriented) elements the opportunity to find their place in the implementation of the Scrum framework. Insiders know that the Scrum Guide recognizes the (possible) need for meetings other than the four Scrum meetings, but calls for them to be kept to a minimum. 

The PSPO 1 exam from Scrum.org (and possibly other exams) contains a question that asks whether it is the Scrum Product Owner’s (PO) primary responsibility to send out regular status reports. The answer to this is (in essence) that the stakeholders should attend the sprint reviews regularly in order to obtain an accurate and up-to-date picture of the maturity level.

But PO’s can’t actually avoid status meetings with stakeholders in day-to-day agile practice, can they?

Even if status meetings, fixed days and steering committees are often perceived as a burden in practice, they still contribute to the empirical Scrum pillars of “transparency”, “review” and the value of “openness”. As with all other meeting formats, it quickly becomes apparent that structure, organization and discipline are significant success factors.

So the basic question of this article is: how can PO’s make reporting and status meetings useful and meaningful?

A few definitions…

Reporting

Any form of written reporting (manually or automatically generated and sent; structured via presentation or report template) to a defined group of recipients. Objectives: fast and standardized information distribution and knowledge acquisition.

Statusmeeting

Meeting of a (defined) group of people, physically or virtually. Objective: detailed and comprehensive information distribution and knowledge acquisition.

Forecasting

Prediction or forecasting model used to recognize a future point in time or event. 

(… as described in the previous blog article Estimations and Story Points, Story Point-estimates → Velocity → Burn down Chart.)

Back to the initial question

Since, in our experience, reports are a) highly standardized and b) mono-directional forms of communication in day-to-day operations, it is recommended to automate such administrative tasks as far as possible. The creation and distribution of reports should require as little or no manual effort as possible. For example, (subscription-based) newsletters or reports from various software tools that are generated and sent automatically are helpful.

The situation is somewhat different with status meetings. Over time, we have identified the following best practices for them:

Regularity

Schedule fixed time slots for reporting and status meetings. In Scrum, a daily Scrum meeting is common, in which the team meets on a daily basis for 15 minutes to discuss progress and any obstacles. In addition, weekly or monthly meetings can be useful for project reviews.

Focus on progress

Reporting and status meetings should focus on the current progress of the project. Share relevant information such as tasks already completed, outstanding to-do’s and any challenges. Avoid excessive discussions or topics that do not directly contribute to the progress of the project.

Clear communication

Ensure that all team members and/or stakeholders have the opportunity to share their input and address any obstacles. Promote open and transparent communication to avoid misunderstandings and to strengthen the team collaboration.

Visualization

Use visual aids (such as burn down charts) to show the progress of the project at a glance. These visual representations make it easier for the team and stakeholders to understand the current status and to recognize trends.

Solution orientation & goal focus

If obstacles or problems arise during a meeting, the focus should be on finding solutions. The team should jointly develop ideas on how to overcome the challenges in order to support each other, achieve the project goal and thus ensure the overall success of the project.

… and what about forecasting?

All forecasting models known to us are based on a mathematical (probability) calculation. The aim is to make a forecast or statement as to when a certain milestone in the project will be reached or when software will reach a certain level of maturity. Influencing factors include:

• Amount of tasks still to be completed
• Required time
• Knowledge building that may be necessary
• Available manpower

These factors can be assigned numbers and used in calculations. The result is then a point in time (or other value that indicates a value for prioritization, depending on the formula used). All familiar calculation formats have two things in common: a work/task list that is a.) defined and b.) estimated.

This alone results in great uncertainty and imprecision. For example, work and task inventories are constantly changing. Estimates are highly subjective and also depend on many other factors (see the previous article of this blog series: Estimations and Story Points).

But how does a PO deal with this? In our experience, the single key to success is a lot of communication. Communicate with the implementation team, the stakeholders and the end users. Changes should be recognized as early as possible and plans (e.g. estimates and forecasts) should be continuously reviewed and adjusted accordingly. Here you go – this is agility by definition.

Product Owner know how difficult it is to design reports and status meetings in a meaningful way. One option would be to reduce such administrative activities to a minimum through automation and time-limited fixed days. However, these should never be omitted completely, as they contribute to the empirical pillars of Scrum “transparency”, “review” and the value of “openness”, as described above.

… and now it’s up to you!

What forms of reporting do you use / send in your daily practice?

What are your experiences and best practices with status meetings?

We look forward to reading your messages! Send them to hello@qualityminds.de