LeadingAgile is Now LiminalArc. Read the Full Announcement

Move beyond isolated AI experiments to build scalable, domain-driven systems with AI-ready architectures.

Enhance valuation and accelerate ROI through due diligence, tech migrations, and strategic restructuring.

Control cloud costs, streamline data, and focus investments on high-value, scalable solutions.

Streamline operations and improve decision-making by aligning your ERP systems with how your business actually works.

Reduce risk and increase resilience by closing the security gaps hiding in your architecture and workflows.

Optimize operations, restructure teams, and modernize technology to maximize the value of digital investments.

Deliver mission-critical software in production-ready increments that create measurable value early.

Reduce risk and complexity with every cycle, turning legacy systems into platforms that can evolve.

The belief that shaped us — and how it evolved into LiminalArc, the natural next step in our journey.

Our team of over 100 experts spans the nation, from consultants and technical architects to product specialists.

We are looking to hire mature, pragmatic consultants who are deeply passionate about meaningful change.

Should You Limit the Size of Work Brought Into a Sprint?

Reading: Should You Limit the Size of Work Brought Into a Sprint?
Should You Limit the Size of Work Brought Into a Sprint?

Listen to the SoundNotes Podcast on the go!

Find and subscribe to SoundNotes on:

In this episode of SoundNotes, we tackle the question of whether or not it’s a good idea for the Development Team to limit the size of work brought into a Sprint. Many teams consider this to be a valuable practice during Sprint Planning or when creating a Definition of Ready. The goal is to make sure that the Development Team is not committing work into a Sprint that they cannot complete during the course of a Sprint. This often shows up as something like “Nothing bigger than an 8” (for teams using Fibonacci to estimate User Story Points). While this practice can be valuable for the Development Team, it also has an impact on the Product Owner and how they prepare work for Sprint Planning.

During the podcast, LeadingAgile SVP and Executive Consultant, Scott Sehlhorst and Senior Consultant Andrew Young talk with Dave about whether or not this practice actually helps and how it can become an impediment for the Product Owner who is trying to plan out work for the Release.

Note from Dave: 

This conversation was very impactful for me in terms of how I think about “ready” and how I think about the work done by the PO in getting ready for the Sprint. Limiting the size of work brought into a Sprint has always been something I have advocated for because I think it helps the Development Team, but I’ve never taken the time to think about how it might create challenges for the PO, who may be far more concerned about the Release than the Sprint.

Links from the Podcast

 

Contacting Scott Sehlhorst

Contacting Andrew Young

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

And if you’re interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at https://liminalarc.co/our-gear/training/

Next Roadmapping Within the Context of the Product Strategy

Leave a comment

Your email address will not be published. Required fields are marked *

×