Dieser Beitrag ist auch verfügbar auf:
In a series of posts in this blog, I would like to address a key question from stakeholders that POs and Scrum teams often hear: “When will this be finished?” In the course of this, I present a mini framework for empirical product goal planning for Scrum. This is currently being developed and tested in several teams and projects, together with several Agile Coaches and POs.
Before I go into the details, I would like to outline the properties of the solution. Why? Because they provide very good arguments that help convince the PO of this procedure. Because, although it is primarily the customer who benefits from it, the PO is the central person without whom it cannot be implemented and become effective.
Empirical product goal planning for Scrum directly via the product backlog
Our approach focuses on providing a planning view for the stakeholder, the PO and the Scrum team. This is intended to provide constantly up-to-date information about the Scrum team’s prioritization and expected completion date of larger projects (aka “product goals”) with as little effort as possible.
In our projects, JIRA has proven itself as a coordination and planning tool. So here’s an example of how we were able to use JIRA to provide such an epic-level planning view:
You could also represent even larger planning levels here, such as “initiatives” etc.
The charm of this representation and our concept for
- the stakeholders: the presentation is intuitive to understand. You can see at a glance when which major project is expected to be completed
- the PO: Changes to the prioritization in the product backlog are immediately visible in the dashboard display. Apart from a well-maintained product backlog and some discipline and focus when scheduling tasks, no other tool is needed to achieve this highly transparent representation.
- the Scrum Master: no separate app or complex programming and maintenance is required. The technical implementation is easy using JIRA’s on-board tools; with simple filters and the product backlog. However, some work is needed on a regular basis to make capacity calculations for future sprints and to support the PO in the planning process. Especially when introducing the concept.
- The Scrum Team: Ideally, it gets product goals, summarized by individual or all of the “big” tasks presented there, clearly presented. It thus gains valuable information about the goals of the PO. The team doesn’t have to do anything that they shouldn’t be doing anyway. In particular, it should support the PO in the refinement and in the planning and prioritization of tasks in the product backlog.
This dashboard view can be implemented analogously for both cloud JIRA and the on-premise version of JIRA.
The gap in empirical project planning for agile projects
For me, empirical project planning is a kind of “holy grail” for agile projects. And one of their biggest weak points and “gaps” in practice. Where I worked as a coach, predictability in long-term planning was repeatedly required by clients, but never empirically provided. Most of the time the PO speaks “from his gut” due to a lack of empirical data. Or “estimation workshops” are conducted to gain the team’s “experience” as to when larger things (often referred to as “epics”) will be completed. Or the planning is dismissed by the PO as a “waterfall approach” and discarded entirely (“Why plan, we are agile!”). Furthermore, planning-relevant information is often distributed across many sources instead of being summarized in the product backlog.
If there is a plan, only a small amount of it will later be reflected in the product backlog. And only a few things are maintained in a timely manner when new findings emerge. In the product backlog you can often be happy if there is at least a more or less realistic plan for the following sprint – the teams there usually plan far too optimistically.
The result of the methods described above is therefore rather static and potentially erratic. Because it has little or nothing to do with the empirical reality on the basis of which we should decide in Scrum projects. It is more reminiscent of an “optimistic blind flight” through the clouds of the agile sky.
A new agile focus on product goal planning for Scrum
In fact, many Agile Coaches don’t seem to be aware of or care about this problem. In my experience, these focus more on short-term predictability within the framework of the next sprint, but hardly beyond that. This is often seen purely in the domain of the PO, but without concrete ideas to support him. And yes, I haven’t found a “recipe” for years to address this problem well.
What I am now specifically helping to introduce to some teams: empirically supported project planning and product goal planning for Scrum over six 2-week sprints (or over 4-5 sprints for monthly sprints). Of course, the number of sprints interpolated into the future is initially a parameter. We are currently experimenting with the specific length: it should cover a sufficient period of time for the stakeholders. And at the same time, it should not be so long that the predictability becomes too poor or the – potentially non-value-creating – planning effort becomes too great.
Details about the concrete implementation will follow… soon!
Our implementation concept can be described so clearly that you can explain the core elements to a PO or coach in about 20 minutes. However, keeping track of it and establishing the subtleties and connections permanently requires further support and insight and would go beyond this article. I will therefore not describe how the product goal planning for Scrum outlined here actually works in this first article, but rather gradually over the next few weeks. Of course, specific case studies with our teams will also be gradually published here in the blog. As for the first impressions, dear reader, that this article has left you with, I look forward to any questions and suggestions!
ADVERTISING on your own behalf: Would you like support from an agile coach? This is possible from around one day per week through Rolf Wendolsky & Partner. Through our digital agency JonDos, we also offer staffing and the establishment of entire development teams for your projects. Preferably organized as Scrum teams, but not only: we also have a lot of experience in the agile organization of “small” “part-time” projects with only 2-3 developers.