August 19, 2015
Release and sprint planning
Choosing requirements from the roadmap to a sprint
It is the product owner who chooses requirements from the roadmap, refines them and moves them to the product backlog. The choice is made based on several parameters, such as value for the customer/business value, resource consumption, the timing for these functionalities should be released, and having a balanced mix of requirements that appeals to different stakeholders.
There may also be other factors that affect the choice, such as whether there are other people than the client who will be affected by the product, such as the client’s customers. Legal requirements may also influence the selection.
Beware of synergies. Do not try to “solve everything” at such an early stage in the process.
The Product Backlog is owned by the product owner. Requirements with the highest business value are placed at the top of the list. The requirements are elaborated in more detail the closer to development they come. The requirements shall be detailed enough in time – not more, not before. The next level/stage is the sprint backlog
The Sprint Backlog is owned by the team. It contains all of the work to be done in a given sprint. Each requirement has an estimated size and acceptance criteria to be used to check if the requirement is met. The requirements in the sprint backlog are more detailed than in the product backlog. A sprint backlog covers one increment, i.e. a product part which is completely done and potentially shippable. The content and length of the sprint must not be changed.
Set a goal for each sprint
The goal should objectively summarize the desired result. The goal gives context, focus and limitation to the sprint. It is best set by the team along with the product owner.
The goal should not be changed during the sprint. It should be realistic, not overly ambitious but not too tame either. Following the SMART guidelines for goal-setting is a practical way to make sure you create achievable goals that are clear and understandable even to people outside the team.
It is very important to set reasonable goals so that they can be reached even if the lowest prioritized requirements are not completed during the sprint.
Tip: If the sprint goal is difficult to define, it may be because the requirements are unclear or do not fit together.
Definition of Done (DoD)
The team formulates their own DoD/definition of done. The definition should be the same for all sprints. The DOD creates clarity in the team and makes it easier to get the right picture of how we are. With a good Definition of Done, you know when the work is done.
Examples of DoD: coding is done; works on the developer’s computer; or passes the test.
The goal should be that the function is completely ready for deployment, including all the work required, e.g. documentation and testing. The most important is that the goal is common to the whole team. The development tasks that are completed are visualized in the done column of a burn-down chart.
Preparing for the sprint planning
It is the product owner who prepares the sprint planning. To do this in a good way one needs to typically take a few hours from the team. Part of the planning involves breaking down the requirements that do not fit in one sprint. Requirements are refined one or two sprints ahead of when they are needed. Just enough and just in time. This can be done during the backlog refinement.
The product owner need always be some sprints ahead of the team. It is not productive to prepare the requirements to be implemented for example ten sprints ahead.
Backlog Refinement is a short meeting where the product owner and scrum master attend before the sprint planning. It makes the sprint planning meeting more efficient because you can filter out requirements that need to be investigated more to be able to be sprint planned. One can also detect requirements that be detailed for the sprint to be ready. If you do not prepare the sprint planning by actively working to make the requirements better, you increase the risk that the sprint planning meeting will be ineffective.
Sprint Planning Meeting
The sprints are planned by the team. An example of the agenda of the meeting:
- The Product Owner explains the requirements
- The team estimates using, e.g. Planning Poker or t-shirt sizes
- Talk about what should be done and how long it is expected to take.
When the meeting is over, there should be a list of estimated requirements for the sprint. The requirements are in order of priority and there is a goal defined for the sprint.
At the sprint planning takes into account the team’s capabilities based on past performance and expected performance. If you normally catch about ten demands, and none of the team members must be idle, one can assume that it will catch the ten demands even in this sprint.
It is also looking at where you are in relation to the previously delivered increment and what is planned in the road folder.
The product owner should participate even when the team estimates the development effort during the sprint planning meeting. The discussions and the collective expertise is important. The reasoning that arise in the estimation increases the product owner’s expertise, even if the product owner is not with and estimates. If the estimate is high, it may be due to uncertainty, then, the requirements clearer. The requirements may need to be broken down further.
Planning Poker
A common estimation technique is planning poker.
The basic arrangement is that the product owner declares the requirement and the team asks questions until they understand the requirement sufficiently. After that, each participant an individual estimation without sharing it with the other. This provides an opportunity for reflection and individual estimation without being affected by the other.
The Planning Poker uses a special deck of cards usually have the following denominations: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and “do not know”. Often choose to scale corresponds to the number of days or ideal days. Keep in mind that the definition of donor, i.e. it is not enough to claim to be ready coded, it should be clear for Deployment.
Once everyone has made their estimates share it with others estimates with the group. It discusses the differences and thereby learns the group about how the others have thought. Then takes another turn and estimates again. Planning Poker benefits from both the individual and the group’s thoughts. The group’s estimation is usually better than the individual.
Visualize the Cross
Another easy way to visualize the priorities is to set them up in a cross.
On one axis are the typical business benefits and on the other is the cost or the time requirement is estimated to take. The cross is very simple to use and gives a visual answer that is often sufficient in helping teams determine the level of priority that should be assigned to a given task or project.
If there is great uncertainty and/or large investment, it is wise to supplement this technique by studying or write a business case on the benefits that can be achieved by pursuing certain goals.
Other Estimation Techniques
Other techniques to estimate the t-shirt sizes, story points, or simply counting the number of claims or patches. If the development of the information is about as many as in the previous sprint, and patches are on average about equal, it is likely that you have time for about as many pieces in the next sprint.
One can also estimate based on how long it takes to develop, such as days or hours. It’s easy to understand and get started with. At the same time, it is easy to get caught up in details.
Ideal Hours is another common scale. It is then assumed that one can devote example, 2/3 of the available working for development. It is more realistic but also more difficult to understand.
None of the estimates can be ever considered to be either right or wrong. It is the team that select and there are advantages and disadvantages to every method. There are even teams who never estimate their work, an approach that is usually referred to as the No Estimates movement.
Share article