Posts

Posted on

How we do involve stakeholders?

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

Posted on

Engage Everyone in Making Sense of Profound Challenges

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

Posted on

If You’re Working on Other Stuff, Say So in the Daily Scrum Inbox

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

Posted on

Four Steps to Keep Your Product Backlog Small and Manageable

You should always strive to keep your product backlog small and manageable. With too many items on the product backlog, three problems arise:

First, it is harder to work with an excessively large product backlog. Time will be lost looking for items. (“I know it’s in here somewhere.”) Prioritizing the backlog will take longer. Duplicate items will appear as it will be easier to add an item “just in case” rather than be sure it’s not already listed.

Second, the development team barely notices any progress they make. A team that finishes 10 of 50 product backlog items can sense that they’ve made progress. A team that finishes the same 10 but out of 1,000 items will not feel the same sense of accomplishment. They will begin to wonder if it would matter if they had only gotten 9 done instead.

  • Delete Things You’ll Never Do
  • Keep Items You Aren’t Ready for Off the Product Backlog
  • Periodically Review the Product Backlog
  • Don’t Add Things Unless You Plan to Do Them Fairly Soon

Read the complete article there: https://www.mountaingoatsoftware.com/blog/four-steps-to-keep-your-product-backlog-small-and-manageable