Category: verified

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