For ones who have either heard of or worked agile, a “Scrum” term arises top of mind. Perhaps, those from 2021 may argue that a Kanban is headmost now, while Scrum is becoming obsolete. Still, until quite recently, as many as 95% of all agile organizations worked right under the latter framework.
The methodology originated in the early 1990s – as a controlling way to manage software development. Its further usage by Fortune 500 companies made Scrum all the go – across the globe. The system includes the 5 impartial values:
- commitment – taking personal responsibility
- openness – communicating while in the teams
- respect – a courtesy when judging about both success and failures
- courage – readiness to undertake challenges
- focus – dealing with a few things at a time.
The latter principle brought on a “sprint” – a several weeks long period, during which the team consolidates efforts towards a particular task or bug. The entire project pipeline, hence, consists of many subsequent “single-minded” stages. To thoroughly arrange sprints, regular and recurrent planning is required.
What is a sprint planning meeting?
A sprint requires all participants to know the big picture – Why, Who, How, How long, and For what purpose the team needs to move along a “project journey” in a certain way. A Scrum sprint planning meeting is exactly where the 5 dilemmas are being addressed. The ultimate goal – to come up with clear performance guidelines for the subsequent 2 to 4 working weeks – for every single project participant.
Let’s briefly recall roles in the team:
- a Scrum master – the one responsible for overall framework’s raise and maintenance
- a Product Owner – the one who triggers development and frames product backlog
- developers – ones who directly perform work and report on tasks.
A sprint planning meeting has a typical scenario of how these 3 project identities interact:
- The Owner informs of the improvements’ rationale and current backlog
- The team – all three roles – discusses what to carry through the upcoming sprint, and what to put on hold
- Developers plan changes and, together with the Product Owner, decide on the time required.
A good plan should also pay regard to teams’ motivation and professional development through challenges.
How to conduct the planning meeting?
Look up the project pipeline
Although a project delivery pipeline is on an equal footing with an agreed documented strategy, this doesn’t mean the plan is a “once and for all” record. Just the reverse – failing to timely review and adjust the initial plan screws it up. Agile presupposes a Continuous Delivery Pipeline (CDP) – an on-demand adjustment of background work. Thanks to this, each particular stage of the pipeline results in a conspicuous added value for the ultimate project owner.
“A CDP approach is iconic for the agile planning”, source
The less pointless activities and communication breakdown are – the higher performing speed and participants’ drive are. If you’re the Product Owner, make sure to review the roadmap previous to the actual meeting. If you use Jira, prepare a short summary on Epics and Versions – to keep abreast of the latest changes that the developers have made to the project.
We also recommend you mapping a sprint before the meeting – to make it more suited to the purpose. You can then make changes during the joint discussion. To prevent messy fiddle with jotting, use digital whiteboards. These are shareable online workspaces that you can administer to keep ideas. For example – by placing online sticky notes and discussing these with teammates during the planning meeting. You can after use notes to create mind-maps of further changes or reorganize them into a neat Kanban board.
Review current backlog
Another prep stage is to assess a Scrum backlog – to get an idea of transmitted, flagged, split issues, and the overall workload under the project.
“This is how a project backlog may look like in Jira”, source
Assure that the team can view all created issues or restrict access to certain ones. Jira users shall consider that the Atlassian by default shows up to 100 issues. So, if your project consists of many epics, go to “Settings” and select to see 100, 500, or – all at once.
Examining the backlog is a good exercise to assure stakeholders’ expectations will be met, in the end. To handle it well, follow the “2-R”s assessing approach that Atlassian does suggest in the matter:
- roadmap – this is the entire scope that you split in separate epics
- requirements – these are clauses for each epic, also called “user stories”.
Prepare the list of assignments you’ll present to developers. Assume what is more of current interest and how it’d be better to ask to organize work over user stories – either within a single epic or from different epics at once.
“The two ways to point up the backlog”, source
If you realized the backlog had bulked up a lot, it would be better to group user stories according to the extent of the least effort required. Compare different states a backlogged task may happen in:
- developers and designers have already negotiated on cooperation, worked out delivery stages, and esteemed production time
- developers and designers have just received a new user story and haven’t scheduled any talks yet.
The first kind of task is more likely to be finished like clockwork because of many prior activities. The second one may put a break on a sprint – as far as requiring a number of clarifications to be done.
Although the Product Owner stands behind re-prioritization, it does matter to always review the backlog with executors and stakeholders. Under other conditions, battles – up to postponing the project’s deadline – will inevitably arise.
Estimate the time demanded
After you’ve ranked user stories, it’s time to calculate costs. In other words – to count development hours required to complete every user story. So, the mathematically correct way to estimate is to:
- calculate average hours needed to either produce one item or for homogenous works. For example, how much does it typically take in your company to layout a single landing page, program a single Class, or add a single client’s data into the database?
- multiply means on the new quality needed
- calculate the variance and adjust the forecast
- weigh the appraised time by the risks’ magnitude.
But merely if none of the teams practice such a detailed statistic, agree. If truth be told, such a long-lasting data collection may be useless, especially if the company functions in a volatile environment (and who doesn’t nowadays?). So estimating time is pretty much guessing – depicting the approximate duration of operations.
A good method is to gather experts, ask them about how long they think a certain task may last, and then – calculate some average. To put an idea into practice, use a silent planning technique.
Create “relevancy columns” – use numbers to visualize time spans, e.g. 1, 2, 3, 5, 8, 13, 21, and 34 hours.
“Ask experts to put every single case into a certain column, depending on the production duration”, source
While announcing the next user story on an agenda, ask participants to place it within one of the columns on the whiteboard. You will see that the time will be estimated the same way by the majority of sprint planning participants. Those most dissonant cases can further be reviewed in more detail.
Assess resources available
You can perform this undertaking alone – before or after the sprint planning meeting. However, it’s better to determine a capacity in partnership with developers, because the Product Owner may not be aware of the actual team productivity.
The capacity is a mathematical size of means that one possesses. It is calculated by multiplying the quantity of personnel on working hours per employee. Say, if your team embodies 10 developers and an 8-hours working day, the project capacity will be: 10*8 = 80 hours.
But bare arithmetic is a narrow approach to estimate resources. If everything was so simple, there wouldn’t be so many inaccurate cost predictions in project management. To perform more careful resources’ appraisals, pay attention to:
- the budget – can you afford extra hiring in case someone leaves the team or if urgent situations occur?
- a provision with hard- & software – are members fully and equally equipped to start the sprint right away?
- scheduled vacations & public holidays & current sick leaves – whom from personnel would you commit to for the sprint?
- the team’s overall atmosphere and “vibes” – what is the motivation degree? are teammates inspired with a previous success or demotivated – because of a previous failure? are there evident vested interests? and so on.
Communicate the next steps to the team
After a sprint planning meeting is over, it’s time to communicate an action plan with the team. Make sure that everyone catches the goal and knows what to do. Jira users can utilize a “Create sprint” option – to drag and drop relevant tasks on a sprint noticeboard. Click “Start sprint” to begin the loop.
“Software helps arranging tasks in sprints more clear-cut”, source
You can refer to the footer – to explore estimated works and quantity of in-the-sprint issues. There may only be one active sprint at a time – even though one may continue working out another sprint from the backlog.
To-Do’s during an agile sprint planning
Meetings don’t always go as planned. To avoid amendments or mistaken interpretations, equip oneself with a “To-Do” checklist:
- Group issues from the backlog into alike groups
- Discuss groups with participants – approve issues for the next sprint
- Review the input on sprint resources from the production team
- Double-check if the esteems were accurate and agree whom exactly to assign for works
- Run a short Q&A session so that everybody can express concerns or suggestions.
A thorough legwork, a cooperative atmosphere, time limits, and a clear agenda – are the basis for a good sprint planning meeting. Agile comes across as stunning in terms of effectiveness, but if you want to experience the benefits, then managing the backlog and resources shall become of the utmost importance.
