Skip to main content

Proposed Solutions for Items not yet on Sprint Backlog

Last post 10:43 am January 25, 2019 by Ian Mitchell
3 replies
03:18 am January 25, 2019

In my current company, we have the following events during a sprint.

> *Story Time 1 - BA discusses the requirement to the Dev Team, happens multiple time during the whole sprint

> *Story Time 2 - Dev Team discusses the Proposed Solutions, Testing Ideas and Hour Estimates, happens few days after Story Time 1

> Backlog Refinement - PO, SMEs and Leads discussing the final priorities based on teams proposed solutions, testing ideas and hour estimates

> Sprint Planning - locking in items to be part of the sprint backlog and creation of Sprint Goal

> Daily Stand-up

> Sprint Review

> Sprint Retro

Given all these events, are we doing it based on the Scrum Guide? Are we violating any pillars of Scrum or Agile Principles?


06:08 am January 25, 2019

By contrasting your team’s implementation with the Scrum Guide, what observations would you make yourself? How do the “events” you describe compare, and the roles you mention? What about rules - should items be locked-in, for example? Where there are discrepancies, what problem are they meant to solve?


07:11 am January 25, 2019

Actually, this is not the way I've known Agile and Scrum. I have just recently joined a company as a Scrum Master, and they have just implemented this process a few weeks or months before I started.

It's good that collaborations, whichever you want to call it, happens before the Sprint Planning. However, I don't believe that the development team should think of specific proposed solutions (as in document the specific classes and methods they will be changing, or a detailed coding strategy to implement an item, or create test scripts that will be followed during manual testing) before the team decides to include on the sprint since priorities, requirements, clients needs and/or market can change. Creating detailed propose solutions and test cases for items not yet part of the sprint is not exactly aligned with the principle "Simplicity--the art of maximizing the amount of work not done--is essential".


10:43 am January 25, 2019

I think you make a fair analysis, and it seems like you are in a position to make your own critical assessment. Perhaps the issue to be focused on is not so much the “violation” of Scrum’s pillars and agile principles, but whether or not Scrum is being implemented well.


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.