Overcoming Challenges in Sprint Planning: Insights Needed

Estimating User Stories: Our team struggles with providing accurate estimates for user stories. We tend to spend too much time debating the estimates, which ultimately reduces the time we have for the rest of the planning process. How do you strike a balance between discussing the estimates in detail and keeping the meeting productive and on schedule?

Estimating is a divisive issue. Although some people and teams find estimating helpful, it's not without risks. The No Estimates movement captures alternatives. In any discussion of estimation and estimates, I find it beneficial to agree on what problem the team is trying to solve by estimation and then that estimation is the right tool to solve that problem. The team may find that estimation, or at least estimation as they are doing it, isn't the right fit.

If the team decides that estimation is appropriate, I would look at the team's refinement practices. Teams should have a well-refined Product Backlog going into Sprint Planning. Feedback from the Sprint Review and Sprint Retrospective could impact the items in the Product Backlog or their ordering, so there may need to be some refinement between the Sprint Retrospective and Sprint Planning or at the Sprint Planning event itself. However, having most items understood, decomposed, and, if necessary, estimated before Sprint Planning will help keep the Sprint Planning event more productive.

Defining a Clear Sprint Goal: We often have difficulty setting a clear and achievable Sprint Goal. Sometimes, the goals we set are either too vague or overly ambitious. What techniques or strategies have you found effective for ensuring the Sprint Goal is both clear and realistic?

I've found that an iterative approach works best, especially when combined with a well-refined Product Backlog. The Product Owner should walk into the Sprint Planning event with an idea for a Sprint Goal that moves the product closer to the Product Goal. The team can talk about it briefly, develop a shared understanding, and then start selecting the Product Backlog Items that support that goal. After selecting all the items the team believes are required to meet the Sprint Goal, the team can use forecasting techniques to see if completing the work is realistic - points and velocity, ideal hours and calendar hours, throughput, or some other tool. If the work is not likely to be completed, the team should negotiate a smaller Sprint Goal and repeat until the team is comfortable that the work needed to achieve the Sprint Goal can be completed within the Sprint.

Personally, I find it helpful to leave room for error. If the team believes they can complete 50 points of work, 35 ideal hours of work, or 14 Product Backlog Items, the work needed to achieve the Sprint Goal should be less than 50 points, 35 ideal hours, or 14 Product Backlog Items. I find planning on 75-80% of capacity to give some room for unplanned work. I would want a Sprint Goal requiring 37-40 points, 26-28 ideal hours, or 10-11 Product Backlog Items.

Managing Uncertainty: Some team members are hesitant to commit to user stories due to uncertainty about the requirements or potential technical challenges. How can I help the team feel more confident in their commitments without the risk of overpromising or overcommitting?

The team doesn't commit to user stories or Product Backlog Items. The team commits to the Sprint Goal. The technique I mentioned before about ensuring that there's room for unplanned work based on the team's capacity can help. Depending on the overall risk tolerance of the organization, you may want to adjust how much room you leave for unplanned work. An organization that has low tolerance for failing to meet a Sprint Goal may, for example, want a Sprint Goal that is likely to be achieved in 55% or 60% of the team's capacity, leaving much more room for unplanned work or challenges. An organization that has a very high tolerance may have the Sprint Goal consume even more of the team's forecast capacity.

Ensuring Balanced Team Input: During our Sprint Planning meetings, there’s a tendency for the more vocal team members to dominate the conversation, while quieter members tend to hold back. What are some strategies you use to make sure that everyone’s voice is heard and all perspectives are considered?

This is the responsibility of the Scrum Master. There are different techniques, but one could be to explicitly stop the more vocal people from talking and ask explicit questions to the quieter members. However, it may be worth talking to the quieter people to understand why they are quiet.

Maintaining a Refined Product Backlog: Our product backlog often includes items that aren’t well-defined or properly prioritized, which makes it difficult to plan effectively. Do you have any best practices or tools you use to keep the backlog in good shape, so we have a solid set of user stories ready for each sprint?

I find it useful to keep the "top" of the Product Backlog well-refined. How much of the Product Backlog should be refined depends on the volatility of your environment. In a highly stable environment, I'd expect about 6-8 weeks of work to be well-refined. In a highly volatile environment, perhaps only 2-4 weeks of work. You can use your Sprint length plus techniques like velocity or throughput to turn this into a count of Product Backlog Items. If the amount of work in the Product Backlog isn't refined, the team should invest additional time in refinement.

Once the team is investing the time into refinement and is taking this consideration into Sprint Planning for future Sprints, you can use Sprint Retrospectives and refinement to dig into techniques and tools for improving the refinement process.

Estimating User Stories: Our team struggles with providing accurate estimates for user stories. We tend to spend too much time debating the estimates, which ultimately reduces the time we have for the rest of the planning process. How do you strike a balance between discussing the estimates in detail and keeping the meeting productive and on schedule?

Don't even try to provide accurate estimates. Provide rough ones which are fit for purpose. Anything more is waste. The only purpose of estimation in Scrum is to help the Developers get their arms around how much work they can take on in a Sprint. If they were to look at a selection of user stories and say "that's about the right amount of work" then that's fine. We need expect no more from them in terms of estimation than that.

Defining a Clear Sprint Goal: We often have difficulty setting a clear and achievable Sprint Goal. Sometimes, the goals we set are either too vague or overly ambitious. What techniques or strategies have you found effective for ensuring the Sprint Goal is both clear and realistic?

What product hypothesis is worth testing this Sprint? Scrum is about innovation, and learning to build the right thing at the right time.

Managing Uncertainty: Some team members are hesitant to commit to user stories due to uncertainty about the requirements or potential technical challenges. How can I help the team feel more confident in their commitments without the risk of overpromising or overcommitting?

User stories would be a strange thing for people to commit to. Jointly committing to a Sprint Goal, which mitigates a significant product risk or uncertainty, and a Definition of Done, which guarantees product quality, would be more sensible.

Ensuring Balanced Team Input: During our Sprint Planning meetings, there’s a tendency for the more vocal team members to dominate the conversation, while quieter members tend to hold back. What are some strategies you use to make sure that everyone’s voice is heard and all perspectives are considered?

Are the team aware that this is happening? The first thing to do is to establish transparency over the situation, and then to consider the consequences.

Maintaining a Refined Product Backlog: Our product backlog often includes items that aren’t well-defined or properly prioritized, which makes it difficult to plan effectively. Do you have any best practices or tools you use to keep the backlog in good shape, so we have a solid set of user stories ready for each sprint?

Enough work should be refined and ready, at the time of Sprint Planning, so a coherent selection can be made which would achieve a meaningful Sprint Goal. If enough work isn't refined and ready, perhaps more time needs to be spent on refinement. Ten percent of a team's time is not unreasonable and more may be necessary. Just don't aim to have a fully refined Product Backlog which is then maintained. Instead, continually refine a Product Backlog in order to maintain it. 
 

Hi Emmanuel - My advice to you would be to take a step back and observe how Scrum is practiced and learn from it and refine wherever necessary. It is very important to understand the right problem to solve (what is blocking the value delivery). As you already might have experienced, Scrum is not prescriptive and hence there comes in challenges during the implementation and it is difficult to have a one size fits all solution.

Estimating User Stories: Our team struggles with providing accurate estimates for user stories. We tend to spend too much time debating the estimates, which ultimately reduces the time we have for the rest of the planning process. How do you strike a balance between discussing the estimates in detail and keeping the meeting productive and on schedule?

What is an accurate estimate ?. I am not sure what estimation technique you use. Using a relative estimation will help get better and faster agreement (you might have to coach the teams on relative estimation). When I had this issue I have used T-shirt sizing first for high level classification and the proceed to story points (for some teams story points were being used but getting an agreement was a bit hard). Use the INVEST criteria and ensure that stories are something which the team can accomplish in the sprint as that is more important. If you find the team estimating something beyond Medium it is a red flag that the story might actually not be completed in the sprint.

Defining a Clear Sprint Goal: We often have difficulty setting a clear and achievable Sprint Goal. Sometimes, the goals we set are either too vague or overly ambitious. What techniques or strategies have you found effective for ensuring the Sprint Goal is both clear and realistic?

Use the SMART acronym to set the goal but sometimes it is indeed not possible to do that. I have had cases where we have worked backwards like what is it, we think we can put for the sprint review when the sprint ends and formulate a goal (which takes us closer to the product goal). I have also had teams set goals based on items selected for the sprint. If having a single sprint goal is not possible you could have multiple goals but ensure the teams are committing to the goals and help each other to achieve it at the end of the sprint.

Managing Uncertainty: Some team members are hesitant to commit to user stories due to uncertainty about the requirements or potential technical challenges. How can I help the team feel more confident in their commitments without the risk of overpromising or overcommitting?

Let the team commit to the sprint goals and not individual stories. As a team is there an agreement ? Can the product owner pitch in and clarify doubts ? If there are technical challenges if the team agrees then they could do a spike and get more clarity on how to accomplish something. So in this case the spike will come into the current sprint and once the clarity is available, pull the actual user story. Regarding overcommitment, best to discuss this during the retrospective and see how we can improve. May be the team did feel confident that they could accomplish them but could not do so because of some issues. Keep velocity as a guardrail (also put in some buffer).

Ensuring Balanced Team Input: During our Sprint Planning meetings, there’s a tendency for the more vocal team members to dominate the conversation, while quieter members tend to hold back. What are some strategies you use to make sure that everyone’s voice is heard and all perspectives are considered?

Does the team see a problem here (or is it your perception)? A simple step you can take is to ask if there is a consensus on what was discussed and is there any other point of view (go around the room if needed). If you sense, there is a problem hold an Anonymous retrospective and see if people come out with this issue (this will help understand if there is actually a problem to fix).

Maintaining a Refined Product Backlog: Our product backlog often includes items that aren’t well-defined or properly prioritized, which makes it difficult to plan effectively. Do you have any best practices or tools you use to keep the backlog in good shape, so we have a solid set of user stories ready for each sprint?

Refinement is an ongoing activity, and you can ask the team to have some capacity dedicated to refinement. With the Product owner, decide on the most important items for the next 3 sprints (6 weeks) and work on refining those items. I normally keep one refinement session every sprint (before the sprint planning) with the whole team so that the team is actively involved in the refinement exercise and are also aware of what is in the pipeline for them. Before this refinement session, I would expect the product owner to bring out the next set of critical items (as per the product goal) and the team as a whole can work on refining them

Good advice has already been shared, so here are a few quick points from my experience working with teams:

1. Estimating User Stories: Estimates are just estimates, but people can sometimes be defensive about theirs. To avoid drawn-out discussions, limit estimation rounds. If there is still no agreement, go with the majority estimate, or in case of a tie, pick the more conservative number. 

It is crucial that estimates come from the team, not the Scrum Master or Product Owner. To improve at estimating, discuss discrepancies between estimates and actual effort during retrospectives. Teams often aim to create impressive plans, but the focus should be on delivering value, not having a perfect plan.

2. Defining a Sprint Goal: Sprint goals can be challenging to define. Focus on the primary objective of the sprint rather than specific tickets.

For example, instead of "Complete the top 4 items," use goals like "Enable users to change their contact details", "Activate the new payment option", or “Enable client ABC to upgrade”. This keeps the team focused on outcomes rather than tasks.

3. Managing Uncertainty: Team members may hesitate to commit to a goal or work they feel is unachievable. Hesitation often indicates that some members weren’t fully involved in sprint planning decisions. The decision should always be a team decision. Alternatively if there is uncertainty in work items, then that uncertainty should be reflected in the plan.

4. Ensuring Balanced Team Input: I find balancing contributions can be tricky. A simple approach is to directly ask quieter team members for their opinions or go around the room and give everybody a chance to speak. Emphasize to the team that everyone's input is valuable and necessary for success.

5. Maintaining a Refined Product Backlog: Work with the business representative or Product Owner (PO) to ensure the PO facilitates enough prioritized items in a "ready" state for the next one to two sprints.