You are the Scrum Master of the Maven’s team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.
The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master?
Solution: The sizing of backlog items helps forecast what will be achieved within the sprint and how many sprints it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.
Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner.
Would like to know your views.
