Category: verified

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

3 Veelgehoorde Misvattingen over Lean en Scrum

Krijg jij met regelmaat aantal vragen over de relatie tussen Lean en Scrum?, Hier wordt in dit blog aandacht aan besteed door de Agile Scrum Group. Deze vragen zijn bestempeld als in de volgende misvattingen:

  • Lean is voor processen en Scrum is voor projecten
  • Lean is voor bestaande zaken en Scrum is voor innovatie
  • We hadden eerst Lean, nu gaan we scrummen
  • Lean en Scrum moeten bottom-up ontstaan
  • Na een theorie training bén je Scrum Master of Yellow/ Green/ Orange Belt
  • Je moet kiezen als organisatie tussen de Lean en agile filosofie

Lees het volledige artikel hier: https://agilescrumgroup.nl/misvattingen-lean-scrum/

Posted on

Six Agile Product Development Myths – Busted

In this article Mike Cohn busts six agile product development myths:

  • Myth #1: Isn’t Agile Just for Software Development?
  • Myth #2: Is It True That Managers Have No Role in Agile?
  • Myth #3: Can’t Stakeholders Introduce Change Whenever They Want?
  • Myth #4: Doesn’t Everyone Need to Be a Generalist on an Agile Team?
  • Myth #5: I’ve Heard that Agile Teams Don’t (or Can’t) Plan.
  • Myth #6: Don’t Agile Teams Create Products with No Architectural Plan?

Find the complete article here: https://www.mountaingoatsoftware.com/blog/six-agile-product-development-myths-busted