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
The Circle of Influence — A story about taking ownership
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://medium.com/@randy.keyers_19497/the-circle-of-influence-a-story-about-taking-ownership-cd5edea6d444
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
Liberating What?
A great introduction to Liberating Structures can be found here: https://medium.com/@jelrikvh/liberating-what-36e8d511cb89
Liberating Structures in practice: The UX Fishbowl
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
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
Three Reasons Why Your Product Doesn’t Need a Technical Product Owner
Your product does not need a “Technical Product Owner.”
Instead, you just need one product owner who listens to suggestions from all stakeholders, evaluates their ideas, and then prioritizes across all available ideas.
Because the development team members are stakeholders, this means the product owner should consider their ideas and technical suggestions alongside the input from other stakeholders.
The product owner does not need to prioritize all of the things the team asks for, just as the product owner does not need to prioritize everything customers or users request.
But, the product owner owes it to all stakeholders–including the team–to at least consider their requests, and then make prioritization decisions based on both technical and business considerations.
Despite this, some organizations still introduce a technical product owner role, usually allocating that person some percentage of the team’s time and authority over how that time is spent.
This is a mistake for three reasons:
First, any development team member should be able to request that something technical is worked on. This shouldn’t have to be funneled through a technical product owner.
Second, allocating a fixed amount or percentage of the team’s time every iteration to the technical product owner is too simplistic. A stated percentage may work out well over an adequate number of iterations. But there’s no way a fixed split between technical work and new features will be correct every single sprint.
Third, having both a technical product owner and a functionality product owner leads to confusion and needless overhead. For example, who gets to decide if an abnormal termination would be appropriate? If the team is running behind and needs to drop something, which product owner’s work gets dropped? Always?
You can avoid all these complications by having just the one, normal, overall product owner.
That product owner does not need to be deeply technical. Just as
Questions like these can help:
- Why do we need to do that?, and
- What would happen if we did it a few months from now instead?
- What happens if we don’t do this at all?
- What is the second-best option to doing this and why did you reject that?
Combined with a trusting relationship with the development team, this
Having a product owner prioritize all work, including technical work, rather than relying on a technical product owner 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. Subscribe here: https://www.mountaingoatsoftware.com/subscribe