Advice on Sprint Planning

How are they currently formulating their Sprint Backlog, and tracking the work that remains in it?

In my experience with teams, there are several objectives with the Sprint Planning Part 2 meeting:

- Evaluate the "offer" of stories from the business, as it relates to the agreed-to Sprint Goal. Determine from a capacity standpoint, a measurement of past velocity, and an overall "comfort" level within the team, whether the proposed Sprint Backlog is achievable within the upcoming sprint. Consult the Product Owner if there are any questions or concerns around the proposed offer.

- Once the team confirms their forecast (not a commitment/contract!) of Sprint Backlog items that they feel they can complete, and will satisfy the Sprint Goal, they should ensure that there are several options within the team regardign who may work on a story, and what potential solutions there may be to meet the acceptance criteria. This is a discussion not only around flexibility (agility) within the team for meeting the sprint objectives, but also risk management to identify contingencies for potential issues and impediments.

- It is up to the team whether they choose to use Sprint Planning Part 2 to define the story tasks and get into deeper technical discussions. While these activities and discussions are needed, they can certainly occur outside of Sprint Planning.

Hope that this helps. Whenever in doubt though, try as much as possible to defer to your team to gauge how they would like to manage it (ask: "What do you think?"). Good luck.

Posted By Ian Mitchell on 08 Dec 2016 09:55 PM
How are they currently formulating their Sprint Backlog, and tracking the work that remains in it?

Once we are in Sprint Planning our PO shows what he believes is most valuable for the Sprint. We will discuss how much we believe is achievable this sprint and then we start pulling in items. For each item we deliberate how much effort it will take and any problems we foresee. If it is feasible for the Sprint, then we add it to the Sprint Backlog.

As for tracking the work, we have a board up with all of the Backlog Items on it. The board has areas from "Backlong" and "In Progress" to "Testing" and "Ready for Review". The progress is easy to see at any moment in time.

@Timothy Baffa:
Thank you for all of that information. I was thinking that Part 2 of Sprint planning had to happen in the meeting. When your team would meet up for Part 2 of Sprint Planning, how detailed did the discussions get? I know each team will deal with this part differently but I am curious how others have done it.

> Once we are in Sprint Planning our PO shows what he believes
> is most valuable for the Sprint. We will discuss how much we
> believe is achievable this sprint and then we start pulling in
> items. For each item we deliberate how much effort it will take
> and any problems we foresee. If it is feasible for the Sprint,
> then we add it to the Sprint Backlog.
>
> As for tracking the work, we have a board up with all of the
> Backlog Items on it. The board has areas from "Backlong"
> and "In Progress" to "Testing" and "Ready for Review". The
> progress is easy to see at any moment in time.

There isn't necessarily anything wrong with an approach like this. It's very minimal, but from what you say the team seem to have their plan. They also appear to have visibility over the work they believe to remain. Scrum does not require a team to have anything more elaborate than this.

Why do you suspect that "a more robust discussion" might be beneficial? Are the team actually delivering increments of release quality to the Product Owner each and every sprint? Is waste being incurred through not having a more detailed forecast of work?

When your team would meet up for Part 2 of Sprint Planning, how detailed did the discussions get? I know each team will deal with this part differently but I am curious how others have done it.

I have served teams that have been detailed in their Part 2 discussions. I've served teams that have kept it lightweight, and very minimal in story discussion. There are positives and potential negatives in each approach.

Do you incur the effort expense to get into the weeds on stories(design, task definition) that not everyone on the team will actually be involved with? Do you conduct story discussions at a high level, but run the risk of unearthing issues mid-sprint that may have been identifiable earlier?

It is really up to the team as to their preference. What is key is to ensure that the team understands the possible options, the pluses and minuses with each approach, and to discuss whether it is working as optimally as possible (retrospective).

Posted By Ian Mitchell on 12 Dec 2016 03:44 PM
(...)

Why do you suspect that "a more robust discussion" might be beneficial? Are the team actually delivering increments of release quality to the Product Owner each and every sprint? Is waste being incurred through not having a more detailed forecast of work?

Our team has been producing consistently every Sprint. The reason I brought this all up is when I start working on complicated PBI's I have a few questions on the details of how to approach the work. This breaks the flow for my lead developer as we discuss strategies. I never took note of this until I read about Part 2 and its mention of doing this planning ahead of time. I figured this would be a logical place to have this open discussion, but I wanted to see if other teams have done this before.

Is your Scrum Master aware of the situation? He or she should be coaching the implementation of a Part 2 which is adequate for the planning purposes of the whole team. If not, this is something to raise no later than the next Sprint Retrospective.

Can you explain what you mean by Lead Developer? In SCRUM there are no roles besides Developer, Scrum Master and PO. There are no exceptions to this rule.