Advice on Sprint Planning

Last post 11:28 am December 29, 2016
by Markus Pfundstein
9 replies
Author
Messages
06:55 pm December 8, 2016

Hey all,

I am a junior developer and relatively new to the practice of Scrum. I am studying for PSM I and I am curious how other Scrum Teams deal with Part 2 of Sprint Planning (How the work will be achieved).

The current development team I am on has a brief discussion about how each PBI will be worked on as we pull them in. This is just a few sentences about how many headaches we may come across, if there will be issues with testing, and so on; nothing terribly deep is discussed. I can understand the benefit of this, but I believe we might benefit from a more robust discussion. How do you all handle this stage of planning? This is something I would like to bring up in our next Sprint Retrospective.

Any advice on this subject would help me tremendously.

Regards,

MP

09:55 pm December 8, 2016

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

03:22 pm December 9, 2016

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.

12:56 pm December 12, 2016

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.

01:02 pm December 12, 2016

@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.

03:44 pm December 12, 2016

> 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?

07:16 pm December 12, 2016

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).

09:59 pm December 12, 2016

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.

10:17 pm December 12, 2016

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.

11:28 am December 29, 2016

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.