Sprint planning – technical Stories.

This is work to facilitate the creation and support of a product or service.

Refactoring is the redesign of parts or even the entire product. It can be caused by errors in design, insufficient qualification of engineers, significant changes in requirements, lack of a unified development policy, accumulated “technical debt”, etc.
With SCRUM, the need for refactoring can be more urgent than with rigid methodologies. The product architecture laid out in the first iterations may not take into account the multiple changes in development directions that have occurred in subsequent sprints.
There is one problem with technical stories. Once the team has put them in the product backlog, the product owner can set them a low priority. The fact is that most technical stories are not user stories, but team stories. The direct business value of technical stories is often zero. Customers usually have a hard time convincing them to invest in saving the time and effort of the implementers.
There are several ways to solve this problem.

• Make technical stories out of technical ones by finding benefits for the customer. These benefits should be sought in improving the stability and speed of the product. The right moment for this is the customer’s dissatisfaction with these characteristics. In this case, technical stories turn into stories for users.
• “Sell” the product’s owner an increase in the team’s efficiency. It is desirable to calculate the regular resource loss of the team and compare it to the resource required to implement the technical stories. It is important to show for how many sprints the cost of implementation will be covered by the performance improvement. Simply put, the product owner may agree to include a technical story in a sprint planning if it results in the team being able to do more work in subsequent sprints.
• Agree with the product owner on the following procedure: If there is a plan ahead of schedule (all stories from the sprint backlog are realized before the end of the sprint), then the team will supplement the sprint backlog with technical stories.
• Agree with the product owner that the maximum number (or volume) of uncovered technical stories will be limited to a certain number. Anything over that limit should go into the backlog of the next sprint planning.

For ease of evaluation, planning, and distribution of work, stories are usually broken down into tasks. These are the individual operations that must be performed for the story to work. They can represent not only parts, but also different kinds of work. For example, there may be tasks to develop the story, test it, document it, etc. Decomposition into tasks and subtasks can be done by the whole team, by one specialist (e.g. an analyst or architect), or by each member of the team for his or her part of the work. If this work could not be done completely during the sprint planning time, it is done in working order during the sprint.
In the next sessions, we’ll continue to look at the sprint planning process. We’ll talk about task evaluation, team performance evaluation, and other aspects of planning.