Essence of planning

Planning with Scrum

Without proper planning your dev projects are likely to fail, so it is highly recommendable to place a lot of focus into getting the planning phase right. So let´s take a closer look into Scrum structure and focus on planning:

Image above lists most essential elements of Scrum:

  1. Backlog – contains list of tickets, usually prepared by product owner in collaboration with scrum master
  2. Each Scrum team have their own backlog
  3. Sprint planning – event where team gathers together in order to plan content that needs to be produced during sprint


  • Usually length of the sprint is something from 1 to 4 weeks
  • According to, one week is relatively narrow timeline for team to complete tickets properly and four weeks tends to be excessive timeframe to keep proper visibility, but this depends on several factors such as
    • Size of the feature(s) to be released
    • Amount of resources in a team
    • Typical release cycle and additional QA processes influencing to the overall amount of work (unit tests, load tests, regression tests and level of test automation) ‘
    • Nature of the business and dev project; in some cases when releasing early and often with rapid feedback cycle, short sprints are serving well
  • Sprint retrospective is a session held at the end of the sprint, where the team analyzes what was achieved during the past sprint and what could have been improved. This session is usually more technically orientated
  • Sprint review is typically held also before beginning of the new sprint. In the review session team analyzes performance achieved during the sprint; what was completed, what was left open and why. Aim of the review session is to make team understand Scrum and general capacity in more details.

Why is it essential to understand team capacity?

Capacity in this context is a definition for story points team has given for each ticket in the sprint planning. When team is planning tickets in Scrum, story points are unit that is measured to evaluate size of each ticket. Fibonacci sequence is typically utilized as metrics and scale for size needs to be adjusted.

Typical mistake can be that Fibonacci´s are used to measure time. Fundamentally it is wrong approach to think story points would indicate time, as they are formed by development team. In principles measuring is done to synchronize views between team members, not to report for top management or alternative stakeholders.

Measuring is done as part of planning in order to create mutual understanding between developers regarding size of the ticket, in other words amount of work required in coding and testing the increment to be implemented through the ticket. Usually voting is part of planning and voting is used to identify potential discrepancy between estimates of each team member view of how to implement ticket. If there are major variances, aim is to create discussion around the topic.

There are variable ways to organize Scrum planning events and multiple factors to take into consideration. is happy to help you, if you need consutancy in setting up or improving you planning processes.



+358 44 360 6090