Skip to main content

Delivery success for large, dependent User Stories

Last post 10:17 pm November 21, 2020 by Ian Mitchell
1 reply
08:57 pm November 21, 2020

I’ve just joined an existing Scrum team and discovered a number of issues.  The team typically does not release to production every sprint, as many stories are interdependent and there is a lot of operational overhead.  The stories tend to be large, 8-13 story points on average, and they have difficulty breaking them down.  Many stories carry over from sprint to sprint because they are too large and have too many external dependencies. How would you approach these challenges?  What processes or frameworks would you use to help the team be more agile? 


10:17 pm November 21, 2020

Let's put the matters of item size and release cadence to one side for the moment.

Does the team, itself, have all of the skills and competencies needed to produce finished work of release quality? If so, what are the external dependencies and operational overhead you refer to?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.