This post is not meant to be another article about what Scrum Planning is. We assume that this concept is already known. If not, we could summarize the following as an introduction.
It is a procedure with a time box, where among all team members (including the Scrum Master), based on a defined goal, it is decided WHAT is done and HOW it is done.
In this article we will focus on the “HOW”. Within the given time box, the development team should decide whether a main topic should be split into small tasks. This means that the work should be organized to ensure that the goals are achieved at the end of the sprint.
Our team works according to the principles of eXtreme programming, such as CI/CD, TDD, Pair Programming, Automation and Devops (as setting).
Taking these principles into account, we have defined some rules that help us to carry out the splitting of the work. These rules are:
- We define individual tasks on the basis of the Definition Of Done (DoD). For this purpose, we specify the DoD at the level of topics into technical tasks and non-technical tasks. This approach helps us to recognize when a task can really be marked as Done.
- We take breaks when someone needs to rest. This is important because although the Scrum Guide defines breaks as a time box event (maximum one hour for sprints lasting one month), we prefer not to have the pressure of a time box. So, our planning (including the award of contracts) will take as long as it has to. In order not to reduce the quality, it is necessary to take breaks between the individual tasks.
- We also define the tasks on the basis of the following time frame: the workload must be Done in one working day. This may seem a bit aggressive, but we do this for several reasons:
- It helps us to recognize deviations.
- If a task takes more than a day to get to Done, we use pair programming (if we don’t already use it) or divide it into another task.
- We avoid bottlenecks: short tasks imply short checks If they are done with pair programming and TDD, it is also not necessary to make a pull request (trunk based development).
- We do not lose sight of the focus, either by setting out in detail an edge case that we need to test during implementation, or by focusing on a refactor that adjusts the technical debt.
- There are fewer blocks and conflicts when multiple developers work on the same branch. The changes arrive quickly on the master branch and are quickly deployed to live/staging.
- When defining tasks we also rely on the source code, with this practice we gain experience how to approach the solution.
- If it is a topic for which there is no previous experience, we involve experienced third parties in the planning to help and advise the team.
- The very complicated tasks are marked as “Pairing mandatory”.
Of course, we don’t have a crystal ball to see if the defined tasks are sufficient or if there might be too many. Especially in the first few weeks when a Scrum team starts work this can happen. But we learn from every sprint and the rules mentioned here help us to achieve more and more successful sprints.
