Tag: Product Owner

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

Posted on

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 the product owner should question stakeholders when they request new functionality, the product owner can question the team when they request time to work on technical things.

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 is usually all a good product owner needs to appropriately prioritize technical work.

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

Posted on

Working with Stakeholders Who Won’t Take No for an Answer

Sign up to receive weekly tips like the one below from Mike Cohn to Help You Succeed with Agile here: https://www.mountaingoatsoftware.com/email-tips

Do your stakeholders have a hard time accepting a “no” from the team? Or put another way, does your team have a hard time telling the stakeholders that what they want is impossible? If the answer to either of those questions is yes, you are not alone.

I’ve found two techniques useful in communicating a “no” so that stakeholders listen and understand.

First, the team should establish a track record of planning projects accurately and meeting most commitments.

You don’t need to be perfect, but if a team meets most of its commitments, the business is more likely to listen when the team says something is impossible.

Second, when telling a stakeholder that a proposed date cannot be achieved, offer alternatives. For example,

  • By what date could the functionality be delivered?
  • Are there especially challenging requirements that could be relaxed to meet the deadline?
  • What could be done to make the date feasible? More people? Stop using the team for second-level support?

Stakeholders often want more than can be delivered by some date. This shouldn’t be the team’s problem alone.

Wanting more than can be delivered must be viewed as a shared problem. A solution can only be found by the business and team working together.

When stakeholders trust the team’s commitment and work together with team members to find solutions, they all succeed with agile.

Posted on

How to Deal with Bad Scrum User Stories as a ScrumMaster

It is common in the early stages of Scrum implementation for there to be misunderstandings about what User Stories are for and what makes them useful. A ScrumMaster’s task is to be able to help the Team and Product Owner when they are faced with ineffective User Stories as they go into Sprint Planning.

Read the complete article here: https://agilepainrelief.com/notesfromatooluser/2019/01/deal-with-bad-scrum-user-stories-as-a-scrummaster.html

Posted on

The Product Management @Scale game: How can Product Owners scale their role?

Now that many organisations are scaling their agile process one way or the other, Product Owners are faced with the challenge of scaling their already busy role. Kai Stevens created The agile product management @scale game that helps Product Owners identify how to focus on the essential product management activities while making sure that other product management activities will be handed over to other members of their team.

Read about it here: https://medium.com/the-liberators/the-product-management-scale-game-a-simple-way-to-figure-out-what-a-product-owner-should-do-cc143cb85ecd

Posted on

Fight Zombie Product Ownership with the Product Ownership Evolution Model

Through our studies, we have found that a lack of true product ownership is one of the main causes of Zombie Scrum. This is puzzling as the Product Owner role as such is clearly described in the Scrum framework. However, you would be hard-pressed to find a company that comes even close to living the role the way it was originally intended. Not because these companies successfully set up the Product Owner role as required by the Scrum Guide and then found out that strong product ownership doesn’t help them solve their problems. For numerous, often very understandable reasons they go a quarter of the way and settle on fitting the Product Owner role into their existing organizational structure.

Read the complete article here: https://medium.com/zombie-scrum-resistance/fight-zombie-product-ownership-with-the-product-ownership-evolution-model-1771643c8ba6

Posted on

My Reading Backlog

I saw some people sharing their reading backlog and thought it was a fun idea to write mine down as well. Looking back at 2018 I was quite surprised how much books I managed to read.

If you know some books I should add to my backlog, please let me know!

A small note: I have not prioritized my todo-list, whenever I finish a book I pick something from it I feel like reading at that moment and start.

Continue reading “My Reading Backlog”