Fredrik Wendt

These questions can shift the focus from solutions and features, to value and utility - useful when a stakeholder's asking for a specific solution.

In the 2020 update of the Scrum Guide, the Sprint Planning section has had a very welcome update. Every part of Scrum has a purpose, a reason to why it's included in the framework, and this update made the purpose - raison d'etre - of the Sprint Planning clearer. Let's see how!

Should the PO really balance the level of technical debt? I just had this conversation yesterday at Sweden's "big" agile conference, Agila Sverige.

A friend sent me an e-mail, asking me to summarize Nexus and the Scaled Professional Scrum class. Here's the gist of what I sent in return. Why Nexus? If you know Scrum, you already know the basic principles and most important things needed to scale Scrum: inspect and adapt cycles, and the importance of working software ("Done" Increment, at least once per Sprint). Nexus is a lightweight framework that augments Scrum so that transparency and accountability isn't muddled and remains clear in a scaled setup. What is Nexus? As many teams contribute to the same product, there's a high chance of running into integration challenges. Those consist not only of software, but also practices, tooling, infrastructure, skill set requirements and other "human-focused" integrations. On top of this, dependencies between teams and work adds to the same sort of challenges. The Nexus framework address this by adding a new role, the Nexus Integration Team (or NIT), and a new artifact, the Nexus Sprint Backlog. The NIT is accountable to make sure we always have working software, a Done, integrated Increment. They're typically a few representatives from all the Scrum teams in the Nexus, and assemble as needed to make sure things don't fall between the cracks. They also make sure all dependencies are visible and dealt with as needed. They strive to see to that all the work still happens in the regular Scrum Teams. The NIT is not an ivory tower construct, where people with their heads in the clouds tell the people on earth what to do: the NIT is constructed from the regular teams, "The NIT is simply a subset of us". The Nexus Sprint Backlog is added to make sure we manage flow of work in the Nexus, and that dependencies we could not get rid of before the Sprint are being handled. The Nexus framework makes Refinement mandatory, where it was a common, but optional, practice in one team Scrum. The reason behind this is simple: dependencies needs to be discovered early so that we can find ways to mitigate them. What does Nexus feel like? Just like when individuals move into a Scrum team, the Scrum team's goals becomes primary focus, and individuals contribute together to that goal to the best of their ability. They move from focusing on individual efficiency, to optimize the effectiveness of the team. In a Nexus, the same pattern applies. Sprint Planning in a Nexus becomes a Nexus Sprint Planning: we find the Nexus' Sprint Goal, that all teams then plan towards. It's common to use a big room planning for this, to make interaction between teams simple and easy, and help dependencies be dealt with as swiftly as possible. As all teams contribute to the same product, a shared Definition of Done guides all teams to understand what work is needed to complete Product Backlog Items. Daily Scrums are preposed with a Nexus Daily Scrum: we start by focusing on the Nexus' Sprint Goals, before we split out and plan how to best meet that goal. Same pattern as in Scrum: focus on the whole (effectiveness, value) before individual parts (efficiency). The Nexus Daily Scrum is not the only time teams meet to collaborate and work out obstacles, but it's a daily event allowing us to take a step back, look at the big picture and make sure we're doing what's most important. Refinement in Nexus is likely to happen several times, and at different levels of composition. One key aspect is to have cross-team refinement, in order to discover dependencies across team boundaries. Time is typically spent to see how we can make the dependency go away: re-architect the solution, slice differently, team up, borrow team members, ... Allowing teams to work without depending on activities or skills outside their team, is instrumental to having work flow in a Nexus. The Sprint Review, as it's centered around a product, doesn't really change. The facilitation of the event will likely be adapted to a format that enables many more people to participate, but as the Nexus only deals with one product, there is just one Sprint Review (not per team). The Nexus Sprint Retrospective is the regular retro augmented with two parts on the Nexus level: we start out by having representatives meet and share observations that they think involve or affect multiple teams. These issues are then brought back into all the teams' regular retrospectives. As all teams attack these issues, we're applying bottom-up intelligence and representatives meet back to select actions to improve our ways of working, processes, etc for the next Sprint. Is Nexus a methodology? No, just like Scrum doesn't provide all the answers to all questions, the same pattern and rule is true for Nexus: it's a lightweight framework, consisting of the minimal parts necessary to support sustainable, complex software product development endeavours. You'll likely add practices that suits your context, and the class Scaled Professional Scrum introduces 50+ such complementary practices, based on experiences from implementing Nexus around the globe.

This is a list of 10 questions a Scrum Master may ask a Product Owner, in order to help coach them in their role.