3

Currently, we have split "Sprint Planning Meeting" into two parts:

  1. SPM1 - This we do at the first day of the sprint. Product owner discusses the stories that have come into the current sprint from Backlog. All stories are already discussed in Backlog so we don't have much here. Mostly we discuss if something was pending or not clear in backlog. Post this meeting, PO makes sure that team has 100% clarity about the stories.

  2. SPM2 - This is a purely technical discussion. We don't include PO here. We break stories into the testable task so that team member gets broad overview what needs to be executed, what is expected of each task, facilitate parallel development.

The problems we are facing:

  1. SPM1 Problem - There are fewer things to discuss. The team is not convinced on exact agenda of the meeting, they say why don't we discuss complete thing in Backlog only. (We have two backlogs in a sprint). The rest dependencies they suggested can be discussed via email etc.
  2. SPM2 Problem - We struggle with creating tasks from stories. We don't have clear idea to what depth things should be discussed. Should discussion include which code layer i.e BL,DAL,UI, what code would be put OR just how different systems would connect with each other i.e. breaking of functionality and leaving rest to the developer?

Some additional context:

  • Team size: 5 developers, 1 tester, 1 Product Owner
  • Sprint length: two weeks
  • Average production experience of developers/tester: 2 years

Are we doing something wrong here? Should we split "Sprint Planning Meeting" into two parts like this, is it standard scrum practice? How should we resolve these problems?

  • How do you select back of items? Do you have a sprint goal? – MrHinsh - Martin Hinshelwood May 7 '17 at 10:11
  • We follow 2-week sprint, do weekly backlog meetings (each of 2 hours). In the first backlog of the sprint, we discuss what would come in the first week of next sprint. In the second backlog, we discuss what would come in the second week of next sprint. As soon as sprint starts, we conduct SPM1 with PO to make sure there is no doubt left after the backlog discussions and the team is ready to execute the sprint. – maverick May 7 '17 at 11:28
  • You don't mention having a Scrum Master as part of the team, or mention the experience of either the SM or PO. That can have a bigger impact that the experience level of your Development Team. – Todd A. Jacobs May 7 '17 at 11:43
2

TL;DR

You have several process problems. Process problems have a cost. Those costs should be visible, and the cost of fixing the problems should be charged against the project to ensure transparency.

You can address your current set of process problems by:

  • Making better use of Backlog Refinement.
  • Having clear Sprint Goals.
  • Writing user stories (aka Product Backlog Items) that meet INVEST criteria.
  • Improving your Sprint Planning process.
  • Practicing continuous improvement through Sprint Retrospectives.
  • Allocating team capacity to process improvement initiatives.

The rest of this really long answer explains why and how you should do these things.

Analysis

Secondary (Symptomatic) Problems

You have several different problems. As I see it, your secondary problems flow from these statements you made in your original post.

  1. The team is not convinced on exact agenda of the meeting[.]

    This is because Backlog Refinement and Sprint Planning are not being properly leveraged.

  2. We struggle with creating tasks from stories.

    This is likely because stories don't meet INVEST criteria, are improperly sized or estimated, or because your team and your sprints lack cohesion.

  3. The rest dependencies they suggested can be discussed via email etc.

    This is a huge project smell. It ignores the agile principle that "[t]he most efficient and effective method of conveying information to and within a development team is face-to-face conversation." It also indicates that the team lacks cohesion, and is failing to find value in the Planning Meeting as currently structured.

Primary Problems

However, the problems above are actually X/Y problems. They are symptoms of a larger process problem. Based on the information provided, I see several primary issues.

  1. You're not using Backlog Refinement to set a clear Sprint Goal for the upcoming Sprint Planning Meeting.
  2. You're allocating too much time for Sprint Planning based on your sprint length.
  3. Your Product Owner is not available for questions during Sprint Backlog development.
  4. Your team needs coaching in effective decomposition and planning techniques.

In short, if you unpack all the problems, it basically comes down to a failure to fully leverage the Scrum process, and an inability to gel as a cohesive team rather than a collection of individuals assigned to the same project. Let's look at some possible solutions.

Solutions

The following solutions address your underlying process and teaming problems, and should therefore also address the specific follow-on issues you raised in your original post. Situations vary, though, so adapt them as needed.

Backlog Refinement and Sprint Goals

Your entire team should be involved in Backlog Refinement. While more mature teams can sometimes get away with just the Scrum Master and Product Owner involved in the meeting, the lack of cohesion in your Sprint Planning sessions could be addressed by making sure everyone leaves Backlog Grooming with a clear goal in mind and a set agenda.

Backlog Refinement is the time for the team to huddle with the Product Owner to determine what features are likely to be in scope for the upcoming Sprint, and to help the Product Owner:

  1. Identify a Sprint Goal that will act as a filter for selecting stories for the upcoming Sprint.
  2. Decompose any themes or epics for Sprint Planning into high-level (not detailed) user stories, e.g. refining them until they are likely to be no more than one Sprint in length.
  3. Prioritize stories on the Product Backlog, answering technical questions that may affect scope, dependency ordering, or other things that impact the Product Owner's perceived value of the stories.

If the team leaves the Backlog Refinement meeting with a Sprint Goal and a pool of potential user stories for the next Sprint, you have an agenda!

Sprint Planning: Story and Task Planning

Allocate less time for your Sprint Planning sessions. As a rule of thumb, I've found that most teams need about 4 hours per week of sprint length for planning. Obviously, this will vary based on project complexity and team maturity, but if you're spending more than 6-8 hours planning a two-week sprint then you may have other process, framework, or skill deficits in play.

At the very beginning of Sprint Planning, the team must estimate it's capacity for the current sprint. This is often the velocity, adjusted for current conditions (e.g. vacations, changes in team composition, or complexity of the current phase of the project). This capacity estimate is used to limit the work that will be planned for the sprint, and to shape the forecast that is created through Sprint Planning.

The first half of Sprint Planning requires the whole team to review the Sprint Goal, and to work with the Product Owner to select stories from the top of the Product Backlog that will fit within a single sprint. This can involve some discussions, estimations, horse-trading, and on-the-fly reprioritization (by the PO) of the Product Backlog. Whether the team pulls one story or many, the team is responsible for popping stories off the top of the Product Backlog based on the team's estimated capacity for the sprint.

The second half of Sprint Planning also requires the whole team, including the Product Owner. This is the part where the team develops the Sprint Backlog, which are the tasks and dependencies needed to get each story to the Definition of Done. While very mature teams can often combine the two steps, most teams need this step to be explicit.

The goal here isn't to do a traditional work breakdown structure. Instead, it's to define the tasks needed to implement the story, or identify information gaps about scope or Definition of Done for a particular story. In other words, you need a rough outline of what needs to be done so that the acceptance criteria for the story is understand before you start working.

As an example, imagine you had a story like:

As a user,
I want to be able to change my username in the system
so that I don't have to call technical support to fix simple typos made during account creation.

A good story has a value consumer (the user), a feature (changing the username), and a context to constrain the scope of the implementation. A great story is often granular enough that the story's tasks are self-evident. If they aren't, you may need to revisit the INVEST criteria for story development.

During Sprint Backlog definition, the team needs to collaboratively figure out:

  1. How they plan to test the feature.
  2. What meetings or planning sessions they need to have to work out implementation details.
  3. What dependencies they may have on other stories, tasks, or resources so that the Sprint Backlog can be prioritized.
  4. Ask the Product Owner any clarifying questions about scope or context that will ensure the team is planning the right tasks.
  5. As a sanity check, whether the identified tasks can still fit within a single sprint.

That's it! If the meeting starts sliding off into detailed discussions of how a developer plans to embiggen a widget, the team has likely missed the point and the Scrum Master needs to referee the process better.

Refine Your Process

If your team lacks cohesion, maturity, or experience with effective Scrum, then issues should be identified and discussed during the Sprint Retrospective. The Product Owner must then create user stories on the Product Backlog so that the team can allocate capacity to addressing the process issues.

For example, if the team struggles with writing stories that meet INVEST criteria, the problems or knowledge gaps should be called out in the retrospective. The Product Owner might then create a user story like:

As a Scrum Team Member,
I want to learn how define Product Backlog Items (PBIs) that are more independent
so that there are fewer dependencies between PBIs during Sprint Planning.

The story should then be estimated, prioritized, and allocated to a future sprint as work. Process issues can't be treated as hidden work or overhead; they must be made explicit, and any tasks associated with them must be explicitly counted against the team's capacity as either estimated work or as unaddressed tech/process debt that reduces available capacity.

In other words, process problems have a cost. Those costs should be visible, and the cost of fixing the problems should be charged against the project to ensure transparency.

  • Can you please tell which all meetings should be held for 2 week sprint, what should be their max. time limit and exact agenda? I got agenda from above answer but it would be better if you can list types of meetings, their duration, meeting's agenda and who audience should be for a 2 week sprint? – maverick May 7 '17 at 11:48
  • 1
    @sahil That's really a separate question. The five formal ceremonies are all defined in the Scrum Guide: Sprint Planning, Daily Scrum (standup), Backlog Refinement, Sprint Review, and Sprint Retrospective. Refine the time box of each meeting to suit your team's maturity, but make sure you have a time box. The only meeting that's strictly fixed is the standup: 15 minutes. And everyone on the Scrum Team, including the Product Owner, should be in every meeting to increase transparency, especially when process maturity is low. – Todd A. Jacobs May 7 '17 at 11:53
  • adventureswithagile.com/2016/01/13/… looks useful. Thanks for the help. – maverick May 7 '17 at 11:58
  • First, parts of the answer are out of question scope. Second, some problems you have described are taken out of the blue. And finally, you are try to sell something as Scrum which isn't Scrum anymore. – Paul Wasilewski May 7 '17 at 12:35
0

It seems to me that problem 2 is one of a new project or team.

With an existing bit of software, or an old bedded in team, everyone will know the overall architecture of the project. Questions like 'where shall we put this business logic' or 'what tech shall we use to solve this problem' have been answered long ago and no discussion is needed.

With a new team or project its best to sort out the basic structure before you start. ie. 'we are making a c# mvc 4 website, hosted in AWS and using a mssql database. such and such JS framework, etc etc'

Get everyone on the same page architecturally so that you have a framework to discuss technical questions when they come up.

0

To split the SPM into two parts it's the classical approach. First part, agreement on sprint backlog and sprint goal (involves PO/Team). Second part, development team discuss how to realize the requirements in the sprint backlog.

SPM1 Problem - There are fewer things to discuss. The team is not convinced on exact agenda of the meeting, they say why don't we discuss complete thing in Backlog only. (We have two backlogs in a sprint). The rest dependencies they suggested can be discussed via email etc.

Sorry, but I don't fully understand your problems. Like I wrote this part is done to get a common understanding and agreement of the sprint backlog and goal. Maybe the problem is that the requirements which should be done in the sprint are not up for discussion at all?

SPM2 Problem - We struggle with creating tasks from stories. We don't have clear idea to what depth things should be discussed. Should discussion include which code layer i.e BL,DAL,UI, what code would be put OR just how different systems would connect with each other i.e. breaking of functionality and leaving rest to the developer?

The important think in the second part is to refine the requirements to individual tasks, get an agreement on who is responsible for a task and define when a task is done.

If design/technical decisions are up for discussion in this meeting or not depends on the team and the complexity of the requirements. It's also possible to wrap such decisions in individual tasks.

I guess the biggest problem you have is that you haven't find a common and regular structure which everybody respects and follows. Talk to your teammates and and try to agree on a procedure which makes clear which decisions are done in SPM2 and which are out of scope.

  • While splitting the Sprint Planning into two parts is traditional the Scrum Guide in the last 5 years has brought those two parts together. How do you know when to stop discussing tge backlog if you have yet to decide if the sprint is at capacity? – MrHinsh - Martin Hinshelwood May 7 '17 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.