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.
The team is not convinced on exact agenda of the meeting[.]
This is because Backlog Refinement and Sprint Planning are not being properly leveraged.
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.
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.
- You're not using Backlog Refinement to set a clear Sprint Goal for the upcoming Sprint Planning Meeting.
- You're allocating too much time for Sprint Planning based on your sprint length.
- Your Product Owner is not available for questions during Sprint Backlog development.
- 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:
- Identify a Sprint Goal that will act as a filter for selecting stories for the upcoming Sprint.
- 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.
- 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:
- How they plan to test the feature.
- What meetings or planning sessions they need to have to work out implementation details.
- What dependencies they may have on other stories, tasks, or resources so that the Sprint Backlog can be prioritized.
- Ask the Product Owner any clarifying questions about scope or context that will ensure the team is planning the right tasks.
- 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.
