Skip to main content

Do tickets need an implementation plan to be considered ready for development

Last post 10:30 pm February 22, 2024 by Daniel Wilhite
3 replies
12:24 am February 22, 2024

Hello! I'm a developer in a scrum team and I'm uncertain about the level of detail required for a ticket before it's considered ready for development. Many discussions suggest that a ticket is ready if it's small enough to be completed within a sprint and the team has sufficient information to begin work.

However, I'm wondering if a detailed implementation plan needs to be agreed upon by the team during the refinement phase before starting development. Also, how should disagreements between team members on implementation approaches for a Product Backlog Item (PBI) be handled? Is it necessary to resolve these differences and include the agreed solution in the ticket before development starts?

07:37 pm February 22, 2024

The relevant quote from the Scrum Guide is:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

There's no universal definition of what attributes or characteristics are necessary for work to be ready. This is something that needs to be determined by each Scrum Team. In my experience, it's often directly related to the risk appetite of the stakeholders. When stakeholders are more sensitive to risks, the team will need to do more up-front work through Product Backlog Refinement to reduce uncertainties and ambiguities with each Product Backlog Item. When stakeholders are less sensitive to risks, the team can defer more decisions to Sprint Planning and even during the Sprint where the work is done. A good measure would be to assess how confident the team is that a given Product Backlog Item can be completed within one Sprint (or a period that is less than one Sprint).

10:30 pm February 22, 2024

As @Thomas points out, there is no "standard".  It is up to the organization and team to make the decision on what makes a Product Backlog Item ready to be introduced into a Sprint.  I have worked with varying degrees of detail across teams.  I have even worked with multiple teams at the same organization that had differing opinions based upon the product space in which they worked. 

how should disagreements between team members on implementation approaches for a Product Backlog Item (PBI) be handled 

Also, up to the team to decide.  As a self-organizing group of individuals, it is best that the group make these kind of decisions.  As a servant-leader, I usually expect some level of disagreement.  The discourse helps a group view situations from more than one perspective and usually helps to drive towards better decisions.  The best thing to do is for everyone to agree to disagree but support each other for whatever decision is made. 

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.