You have learned how to “play” Planning Poker and what Story Points are. Let’s have a look at the next three rules.
Estimates of User Stories are checked and re-estimated in Story Points if necessary.
If Developers determine that a User Story has a smaller/bigger scope than expected, or they simply forgot to reflect something when they first estimated the User Story, it is good to re-estimate the User Story so that it will reflect the effort spent in the Sprint.
Developers select User Stories from the top of the Product Backlog, skipping User Stories that are Not Ready. User Stories can be otherwise skipped only with approval from the Product Owner.
The Product Backlog should be ordered according the priorities set by the Product Owner. There should be enough User Stories in the Ready state for approximately two Sprints ahead. You never know how many User Stories will end up in the Sprint that is currently being planned, but it probably won’t be more than twice than the amount indicated by the current team velocity.
The Ready state means that the User Story meets the criteria of the Definition of Ready. Not sure what that criteria are? In ScrumOne, to avoid long Planning sessions that are time-consuming and exhausting, we want Product Owners to care about the Backlog and work with it regularly. When they do, the refinement sessions are smoother, and having a Backlog of items in the Ready state shortens the Sprint Planning significantly.
What is the Definition of Ready?
Understood by the whole Scrum Team. If anybody from the Scrum team has a question or something is not clear, they can ask.
Has defined acceptance criteria. You can describe how the Product Owner should test the User Story and/or what additional criteria must be met besides the Definition of Done to accept this particular User Story as DONE by a user, customer or other stakeholder. If you don't know the Definition of Done for a particular team, you should contact the Product Owner or Scrum Master of the team.
Has expressed business value. The best is to express the benefits for you and for the company. Clear and significant benefits will make a strong Business Case for the development of the request and will influence its development priority. Without specifying the business value, it is not clear why we are doing the item. Be as specific as possible and include as much data as you can. Concentrate on the reduction of costs, risks or time, an increase in market value, sales or price, improvements in market understanding or team capabilities, etc. Ideally, describe the benefits for each beneficiary individually.
Estimated by the Developers. If the User Story has no estimate, the Product Owner remains “blind” in terms of estimating the likely delivery of functionality.
Smaller than what can be developed in a single Sprint. There should be a working increment created at the end of the Sprint so we can present it in the Sprint Review. If we pull bigger items into the Sprint than we are able to develop, we usually end up moving the items from one Sprint to another. Also, we can only present Product increments in the Review that are successfully completed.
Demonstratable during the Review. If I can't present a given User Story to a Stakeholder in a Review, why am I doing it?
If there is a change in product scope that the Product Owner did not manage to reflect in the Backlog, he or she can state this during the Sprint Planning and adjust the Backlog in the Planning session. Prioritization also helps ensure that the most important things are done first in the spirit of the Minimal Viable Product.
It is necessary to define User Stories as much as possible so that the team can work without distractions. We also want to have stable Sprints, so having clear User Stories helps us refine and estimate them accurately.
It is possible to skip User Stories if that require a certain team member’s skills if that person already has enough work in the Sprint, but remember that User Stories can only be skipped with approval from the Product Owner. They cannot push a User Story into a Sprint, just as Developers should not have free reign to choose whatever they want to take into the Sprint. It all should be mutually agreed upon.
Developers select User Stories only from the Product Backlog and no other source.
There should be only one source of work that we can plan so that we can better predict the amount of work that needs to be delivered towards the product vision and stay aligned with the business strategy.
Everyone on the team knows about all the requests. Having only one source, the Product Backlog, helps track requests from external teams, have an overview of everything in one place and maintain transparency and cooperation with other teams. Everyone has access to the Backlog and knows what we are currently working on.
It is not as easy as you thought, right? And there is still much more to come. Another article will be out in two weeks.
Thank you for reading!