In this article Jasper Alblas talks about the challenges of a Sprint Goal: https://medium.com/@jasperalblas/scrum-from-the-trenches-the-sprint-goal-e7e15203c82f
One of the biggest challenges for Product Owners is to manage stakeholders. Often, there are many of them. And they all have different needs, requirements, and levels of involvement. How do you manage this?
The Stakeholder Map (PDF) is a simple tool that creates transparency and strategies. Print out a large version of the PDF and introduce it to your Scrum Team. Work together to identify all potential stakeholders (or groups) and write them on stickies. Distribute the stakeholders across the quadrants based on their level of influence over the product and their interest in what you are working on. Based on the distribution that emerges, you can devise strategies on how to best involve them:
- Latents: Keep them up-to-date with frequent newsletters or videos and involve them when you need their input;
- Apathetics: Its usually enough to keep this group up-to-date with periodic newsletters or pull-based information (like a website or page on your intranet);
- Promoters: You want to involve this group as extensively as possible. Invite them to your Sprint Reviews, involve them during Refinement and meet with them frequently to re-order the Product Backlog;
- Defenders: These are your biggest fans. Involve them actively by inviting them to your Sprint Reviews. Encourage the Development Team to seek out these people to validate assumptions about what you’re developing;
The stakeholders on the right are the most important at the moment, so focus the bulk of your time and energy on them. However, if you meet the needs of the stakeholders on the left, you can shift them to the right as they become more interested in your product.
Subscribe to The Liberators Newsletter if you want to receive more of these great articles: https://theliberators.com
The purpose of Scrum is to create a potentially releasable Done Product Increment, in order to realize business value. Many teams struggle in improving their Definition of Done. Simon Reindl describes a technique in the following article that allows for greater transparency on what the Definition of Done is, and what the next steps are.
Encourage people to listen and understand each other’s perspective on a profound, shared topic or challenge instead of trying to convince or persuade others to see it your way. In this article, Christiaan Verwijs & Barry Overeem explain how you can use the Liberating Structure “Conversation Café” to achieve this: https://medium.com/the-liberators/engage-everyone-in-making-sense-of-profound-challenges-c66e44ba00f2
Find a collection of free games, templates and format created by Christiaan Verwijs & Barry Overeem : https://medium.com/the-liberators/free-games-templates-formats-and-inspiration-for-scrum-teams-11f40e3fcb22
In this article Christiaan Verwijs & Barry Overeem will bust the myth that the product backlog is only maintained by the Product Owner: https://medium.com/the-liberators/myth-the-product-backlog-is-maintained-exclusively-by-the-product-owner-af51bc62e90f
Randy Keyers tells you about the Circle of Influence that visualizes how people or teams deal with situations or challenges. It can roughly be divided into three behaviors: Influencing, Involved and Detached.
Read the complete article here: https://firstname.lastname@example.org_19497/the-circle-of-influence-a-story-about-taking-ownership-cd5edea6d444
It’s a good idea in the daily scrum for team members to agree to keep the discussion focused on progress toward the sprint goal.
But I like to also encourage some brief mention of work done in the current sprint aimed at having a successful next sprint. This might include:
- A designer saying, “I did some user interviews yesterday and I’m starting to get a really clear idea of how the new screen will work next sprint.”
- A product owner saying, “Yesterday I worked on splitting up some of the stories I’m going to ask for next sprint. (Yes, this implies I want product owners to participate in daily scrums.)
Occasionally, a team member or two may be frustrated by limiting discussion to the current sprint and sometimes a little about the likely next sprint.
This can happen when, for example, a team member gets pulled into work that is valuable for the overall organization but not to the sprint goal. Or perhaps when a team member spends time helping another team.
What I’ve found to work well in these situations is to give the person something to say in the daily scrum that indicates work done on something outside the normal boundaries of what’s discussed in a daily scrum.
The simple phrase, “other stuff,” works well for this.
Suppose I worked on something unrelated to the sprint goal yesterday, I would simply say, “I worked on other stuff.” Since it’s not related to the current or next sprint, that’s really all anyone needs to know.
This works well because it gives me something to say in the daily scrum. Everyone knows my “other stuff” might have taken all day or only ten minutes. So I don’t feel judged by an apparent lack of contribution yesterday.
Having all team members use the same phrase for this type of work can also help the Scrum Master. If, say, three people in a row report working on “other stuff,” the Scrum Master can say, “OK, everyone drop the other stuff. What happened? Did some stakeholder come to steal the whole team yesterday without me noticing?”
Or perhaps, it’s not three people in the same meeting. Instead, it’s the same person multiple days in a row. That, too, serves as a big, audible clue to the Scrum Master that whatever the “other stuff” needs to be discussed, either in the daily scrum or privately at first afterward.
Establishing a code phrase for work done beyond what is normally discussed in the daily scrum is helpful. It allows a team to keep the daily scrum focused while giving people a way to indicate they did work that was outside of the current sprint goal.
This will help your team succeed with agile.
If you want to receive one short tip to improve your use of agile or Scrum direct to your inbox each Thursday like the one above. Subscribe here: https://www.mountaingoatsoftware.com/subscribe
A great introduction to Liberating Structures can be found here: https://medium.com/@jelrikvh/liberating-what-36e8d511cb89
Shift your perspective and see an experience through someone else’s eyes.
In this first part of the Liberating Structures in practice series, Jelrik van Hal outlines practical examples of how he used the UX Fishbowl in the wild.
Read the article here: https://medium.com/@jelrikvh/liberating-structures-in-practice-the-ux-fishbowl-8048ee6282f2