Sprint planning. Each sprint begins with planning. The whole team is assembled for this purpose. The duration of the planning must be limited by the scrum master, otherwise, it can drag on indefinitely.
Input: Product backlog – current product – team performance evaluation.
Exit: Sprint backlog – its goal and plans– 1 time at the beginning of
– In a time-limited meeting format (max 8h per sprint)
– Team and product owner present
– Product owner chooses sprint goal and demonstration date
– Development team self-assesses and assigns tasks
– Time and place for the daily sprint are chosen
At all meetings, one of the tasks of the scrum master is to moderate to avoid wasting the team’s time. Don’t forget that the meeting time is very expensive. Multiply the cost per man-hour by the number of participants and you get the cost per hour of the meeting. Scrum is often criticized for an abundance of group communication, but it is troup communication that creates team interaction that allows you to work more efficiently. However, you shouldn’t go overboard.
Normally, even when planning large 4-week sprints, the planning process should not take more than 8 hours. For smaller sprints, this time should be shorter. Not only the length of the sprint but also the number of people on the team, their qualifications, the complexity and novelty of the tasks planned for the sprint, etc., affects the planning time.
During planning, the product owner does not influence how the team distributes the work. His task is to give out a few top-priority stories from the backlog, explain the requirements to the team in detail, hear their evaluations and suggestions, and adjust their understanding of the desired result if necessary. A big mistake is to conduct sprint planning without the product owner. This eliminates feedback from the interests of the customer, whom you remember the product owner represents.
In addition to the usual user stories that represent product improvements, there are 2 other types of stories:
Defects.
They are also called “errors”, but the word “defect”, in my opinion, more accurately reflects the essence.
All defects that occurred during the sprint must be resolved within the sprint. That is, a story with defects usually does not pass the readiness criterion and cannot get into the increment, so everything newly created must work to complete the sprint. In practice, mistakes made in the sprint are not always detected or not all are corrected during the sprint. For example, the readiness criterion may include no bugs with “critical” and “urgent” priorities, and skip the rest. In either case, uncorrected defects are necessarily put in the product backlog. Prioritizing them is different from features (improvements), so I recommend grouping them separately within the backlog. In teams where this is not done, the product owner prioritizes bugs mixed up with improvements on his own, following his intuition only.
IToallocate team resources between new functionality and fixing defects, the product owner must decide which team resource to allocate to fixing. For example, it could be a rule: During each sprint, devote 20% of the resource to quality improvement. Alternatively, the product owner can flexibly allocate the resource between features and defects for each print, depending on the current quality of the product and the importance of that quality in the current phase. There is a trap that many product owners fall into here. They are interested in quickly building up new product features and demonstrating their value to the customer. Customer confidence and funding usually depend on it. However, if all efforts are thrown at quantity, the quality gradually decreases. A “colossus on clay feet” form- a product with a lot of features, but none of them works properly. At the moment when the customer starts to be indignant about the quality, the product owner starts to allocate more resources to fix it, but by that time, the defects have accumulated so much that the resource is not enough to develop the product. A situation arises where increments include mostly fixes, but the customer is still dissatisfied, because quality is not quickly restored, and product development almost stops. This is a typical failure scenario. Do not follow it. As much as you want to do more of the new stuff, make time for quality in every sprint. The criteria for the right approach can be the following metrics: total number of defects in the product and iIby severity, number of high-priority defects detected per month, and number of defects detected by customers per period. Keep track of them over time.
