Zuzana Gočová
Scrum Master, ERNI Slovakia


Joffrey Zehnder ERNI

Joffrey Zehnder
Principal Consultant, ERNI Switzerland


What planning is about

Planning is the first of the Scrum ceremonies and takes place at the beginning of the sprint. The Scrum team plans the work for the upcoming sprint. The planning has to answer two questions: “What can we deliver in this sprint?” and “Which user stories will we choose to get done?” The basis for this meeting is the product backlog, which the Product Owner prioritises. The result of this meeting is the sprint backlog, consisting of ready Stories that the team can work on during the sprint. The aim of the planning is also to define the goal of the sprint. Present for the planning are the Product Owner, the Scrum Master, who facilitates the meeting, and the whole team of developers (which includes testers and every other role the team consists of).


Factors critical for smooth running

PO preparation and prioritisation

It is important that the PO does the prioritisation of stories in advance, and not during the planning. This means that when we start with the planning, the backlog is already prioritised. It may happen that there are changes during the planning, but the initial priorities should be set.

It is good practice to add story points to a story already during the backlog refinement. If story points are missing, then this is the latest point in time to discuss the story and add story points.


The Scrum Master as a timekeeper

Much of the smooth running depends on the Scrum Master and how they facilitate keeping the timing, ensuring that the planning does not exceed the given time limit and that the discussions stick to the topic.

If the team does a technical deep dive, the Scrum Master has to bring them back to the figurative surface. It is advisable to ask if it is necessary to discuss the technical details in that much depth. The team should be clear on the matter enough to have a good feeling of how they want to achieve the story, but not every little detail needs to be clarified; this can still be done during the sprint.


Time scope

We try to limit the planning to 2 hours, but strictly following the Scrum guide, there is Planning 1 and Planning 2. We aren’t so strict, but pragmatic, and usually just need Planning 1. Please remember that the team sees and discusses the stories at least once already during refinement.

Planning 1 takes around 2 hours for a two-week sprint. The PO walks the team through the prioritised backlog. They explains every story with the latest changes. Then in Planning 2, the team has an in-depth technical discussion. As already said, in our experience, we always have just the Planning 1, but sometimes the team has another meeting as follow-up where they break the stories into subtasks. It is not always needed, but if required, we do it to help the team.


Soft skills

In the Planning, as in every Scrum event, team members are challenged to share their opinion through open communication. Here, trust within the team is needed. Constructive discussion might lead to knowledge sharing and even to a better solution than the first proposal.


The whole team does the estimation

The story estimation is done with the help of Planning Poker Cards (good electronic alternatives also exist if you work with a remote team). All team members should estimate: developers, testers and operations. And yes, the PO as well. Even if someone doesn’t have the knowledge of how things work in the development, after a few sprints they’ll start to get a gut feeling as to how the team sizes stories.

One thing the Scrum Master prepares in advance is the velocity. The forecast of the velocity is needed so that the team knows how many story points they are able to deliver during a sprint. This helps the team to not overcommit themselves and therefore they should be able to deliver what they committed to.


Common pitfalls

Overcommitting of the team

Based on a false idea about the velocity, it may happen that the team commits to too many stories. This means the team is not able to deliver them within the sprint. This disappoints the stakeholders. Also, the opposite case often happens. This leads to a situation where the team has finished the tasks within a week. Of course, further tasks can be taken in additionally. However, it is a clear indication that poor management has taken place.

A countermeasure is the calculation of the velocity and good estimation practices (see above).

A very demanding PO

It is not rare for a PO to be very demanding, having the idea that something should not take that much time to deliver. It may happen that they talk the team into what stories to take and how much time to dedicate to them. Once it doesn’t work out, the PO and the team will then be disappointed for not having completed the sprint goals.

It’s bad practice to tell a team how long something should take to develop. Team members are specialists and know more about solving the problem at hand than anyone else. Having said that, it’s OK for a PO to challenge the team in its estimations. But in the end, the PO needs to respect the team’s decision about a story’s size, whether they like it or not.


The team take stories into the sprint that are not clear enough

This raises risks that the story will not be finished as something may pop up that the team was not counting on. The story needs to be understood by the majority of the team.

Already showing and discussing a story in the refinement stage is a powerful mitigation to that pitfall.


Overly complex stories

(For this example, we assume that a story estimated 1 story point can be done within 1 day. You may need to adapt the numbers below to your current situation.)
If you have a complex story estimated very high, e.g. an 8, it is good to challenge the team and convince them to split it into less complex parts.

In our experience, stories taken into a sprint should range between 1 and 3 SP; in exceptional cases, a 5 when a story really, really cannot be split. An 8 is not acceptable as it means one developer is occupied with it for the entire two weeks of the sprint.


Best Practice Tips

To sum up the entire episode into some of the most important points:

  1. Split huge stories into smaller stories
  2. Have a refined, prioritised backlog
  3. See a story at least 3 times before taking it into the planning
  4. Give the team enough time to look through the backlog
  5. Keep dependencies in mind during planning between teams and between stories


News from ERNI

In our newsroom, you find all our articles, blogs and series entries in one place.

  • 22.11.2023.

    Recognising trends: An insight into regression analysis

    Data plays a very important role in every area of a company. When it comes to data, a distinction is made primarily between operational data and dispositive data. Operational data play an important role, especially in day-to-day business. However, they are not nearly as relevant as dispositive data. This is because these data are collected over a longer period of time and provide an initial insight into the history or the past.

  • 08.11.2023.

    Why do we need digital transformation for medical devices?

    For hospitals, it is not up for discussion as to whether they want to digitalise. The increasing age of the population in western countries and the progressive shortage of medical professionals mean that without digitalisation, the healthcare system will not be able to provide the quality that patients want in the future.

  • 25.10.2023.

    Mastering the challenges of mobile app testing: Strategies for efficient quality assurance

    Discover the unique challenges faced in testing mobile applications and learn how to overcome them effectively. From selecting suitable devices and operating systems to leveraging cloud-based test platforms, test automation and emulators, this article provides seven essential strategies for optimising your mobile app testing process.

  • 11.10.2023.

    Incorporating classical requirements engineering methods in agile software development for a laboratory automation system

    Traditional agile methodologies can sometimes struggle to accommodate the complexity and regulatory requirements of laboratory automation systems, leading to misalignment with stakeholder needs, scope creep, and potential delays. The lack of comprehensive requirements documentation can result in ambiguous expectations and hinder effective communication among cross-functional teams.

  • 27.09.2023.

    Unveiling the power of data: Part III – Navigating challenges and harnessing insights in data-driven projects

    Transforming an idea into a successful machine learning (ML)-based product involves navigating various challenges. In this final part of our series, we delve into two crucial aspects: ensuring 24/7 operation of the product and prioritising user experience (UX).

  • 13.09.2023.

    Exploring Language Models: An overview of LLMs and their practical implementation

    Generative AI models have recently amazed with unprecedented outputs, such as hyper-realistic images, diverse music, coherent texts, and synthetic videos, sparking excitement. Despite this progress, addressing ethical and societal concerns is crucial for responsible and beneficial utilization, guarding against issues like misinformation and manipulation in this AI-powered creative era.

  • 01.09.2023.

    Peter Zuber becomes the new Managing Director of ERNI Switzerland

    ERNI is setting an agenda for growth and innovation with the appointment of Peter Zuber as Managing Director of the Swiss business unit. With his previous experience and expertise, he will further expand the positioning of ERNI Switzerland, as a leading consulting firm for software development and digital innovation.

  • data230.08.2023.

    Unveiling the power of data: Part II – Navigating challenges and harnessing insights in data-driven projects

    The second article from the series on data-driven projects, explores common challenges that arise during their execution. To illustrate these concepts, we will focus on one of ERNI’s latest project called GeoML. This second article focuses on the second part of the GeoML project: Idea2Proof.