Can "unready" items be selected for the upcoming sprint
Hello everyone!
I have a question about the readiness of product backlog items that are pulled in the sprint backlog. In my understanding the top most pbis should meet the INVEST criteria (or the definition of ready) before the sprint planning. Otherwise the sprint planning is also used for the Product Backlog refinement, especially for the items that shall be pulled into the Sprint Backlog. The refinement for the others items occurs durent the next and the upcoming sprints. If the items are not detailed enough there is a big uncertainty of what and even how it could be delivered.
Now i came across the statement that also "unready" items can be selected for the sprint and so for the sprint backlog? Maybe its not mandatory to have a DoR, but i cant imagine working with too big and unclear items, even if i try to break them down during the sprint.
So I am wondering what is your experience and what is the correct interpretation of the scrum guide?
Kind regards
Marc
If a Development Team planned unready items into their Sprint Backlog, how might that affect:
- the commitment team members could make, including to any goals such as the Sprint Goal
- the ability of the Product Owner to account for and explain Sprint value to stakeholders
- transparency over work in progress
My 2 cents are the PBI could be un-ready or even completely new before the Sprint Planning Meeting, because the BPI is new because a competitor just release a bomb last week-end, but in this case the Sprint Planning is a good place to make the PBI ready for the uncoming Sprint.
So my reading of the Scrum Guide is that the PBI should be ready before the end of the Planning meeting.
I think this is a reason why the DOR is not an artifact of Scrum. The PO need the agility to come in the Planning Meeting with completely new PBI in a very competitive market.
In the Sprint Review the stakeholders inspect the latest Increment and the Scrum Team collaborates with stakeholders on what to work on next. It may turn out the Product Backlog has to adapt and emerge with new Product Backlog items, because by being transparent, stakeholders have provided new information to the Product Owner or feedback to the Scrum Team that warrants a change. Perhaps market conditions have changed, forcing a pivot. With this new evidence, would it make sense to work on something no longer needed because it was "ready"?
A definition of ready (not part of Scrum by the way), may be a great tactic for Scrum Teams, as long as they are careful not to make it contractual in nature. But there are times when you can make the Product Backlog Ready at the last responsible moment in Sprint Planning, as Olivier noted.
Customer collaboration over contract negotiation.
Not as a norm, but more as an exception, my team have taken unready items during the sprint planning meeting mainly because It is a part of the outcome without which the product will not be usable.
We have agreed to this with the clear understanding that:
- We have other sufficient PBIs to start working on, and by the end of the first week of the sprint, the unready items will be ready. (It is a 3
- Any scope creep will be added to the backlog and will be taken up in future sprints.
-If the US is not ready by end of the first week, it will be moved back to PBI and another US with equal story point will be taken in.
Not as a norm, but more as an exception, my team have taken unready items during the sprint planning meeting mainly because It is a part of the outcome without which the product will not be usable.
We have agreed to this with the clear understanding that:
- We have other sufficient PBIs to start working on, and by the end of the first week of the sprint, the unready items will be ready.
- Any scope creep will be added to the backlog and will be taken up in future sprints.
-If the US is not ready by end of the first week, it will be moved back to PBI and another US with equal story point will be taken in.