It’s always annoying when something comes up out of the plan and the team must fix it or manage it inside the sprint. Unfortunately, we must deal with unpredictability. Nevertheless, is always good to analyze why we had to deal with those annoyances.
What can be considered an annoyance? In my opinion, we can consider as critical bugs or unplanned change requests, we receive during the sprint or release and we must integrate or fix it within the sprint. In this post, we will approach, in a generic way some reasons for this and if it happens, who will report it into the backlog and which other measures should we consider to keep the sprint in a normal speed.
What can be called annoyances?
In a previous post (Bugs, change requirements and the PO dilemma) I defined what are bugs or defects and what are change requests or change requirement.
So essentially annoyances are bugs and unexpected change requirements. Change requirements make part of the normal product evolution process. A sign of inefficiency can be considered if, with some frequency, we observe the introduction of change requirements during the sprint, new and unplanned stories for implementation when the sprint is already running and/ or the release scope is already agreed. It’s even more critical if it’s referring to radical changes in the feature design, probably impacting over different components.
This is for sure an annoyant scenario for any Development Team. It brings up planning inefficiencies in the product ownership or architectural levels.
Who can identify them?
I would say that, ideally, bugs can be identified by test managers executing multiple test techniques. It’s always bad when a bug is identified for the first time by the user. It shows a poor quality assurance in the product. Often, bugs are written also by key-users, all Dev Team, including Product Owner and Scrum Master can also identify and report bugs in the backlog. And they can come also from a user support line. This will be a topic for a next post, the workflow to report an solve a bug in multiple user support levels. This topic is particularly interesting in a DevOps context.
Often, an unplanned change requirement introduced as described some lines above, can represent a workaround to outline some dependency, which will not enable the product to be deployed as initially designed. In this situation we see the architect and the development team working together to quickly build an outlined option to deliver the feature. Sometimes not the must efficient solution, but one consciently implemented as workaround to be fixed so soon as the dependency is solved.
How should we report those annoyances in the backlog?
When a bug is being reported in the backlog, it is extremely important a good description: severity level, frequency, how can we repeat the occurrence, screenshots, etc. This complete description makes easier the test manager effort to reproduce the bug, and his task will be added a complete technical description of the bug with other type of information like server logs, browser messages, etc. All this tasks have a single goal: to make easier and faster the bug resolution by the Dev Team.
Normally functional change requirements are written by the PO or UX engineer, summarizing the voice of the customer or introducing innovative features, improving workflows to execute features, etc. Non functional requirements, normally are written by the Dev Team, often by the architect who has the explicit role to search permanently for architectural improvements.
CR also can be a new security requirement or a quality requirement or a legal obligation that forces us to adopt product structural changes (e.g. all data privacy laws). In this case, we have non-functional requirements and must be written by the architect or by a senior development team member.
But this is the healthy way how change requirements enter in the backlog! Those are not annoyances.
How should the team deal with this annoyance entered in the middle of the sprint?
In my opinion here enters the Scrum Master negotiation skills, in order to protect the team: if some non planned effort enters in the sprint, the equivalent effort already planned must leave the sprint. What exactly is always a discussion that should be moderated by the Scrum Master, between the Team and the Product Owner.