If delivering business value should be the main goal of a software development project, not all the developers’ activities are contributing to this objective. In his book ” Scrum Shortcuts without Cutting Corners”, Ilan Goldstein discusses how you should deal with bugs and the technical aspects of your software project.
I like Henrik Kniberg’s straightforward definition of technical stories from his book Lean from the Trenches (2011): “Technical stories are things that need to get done but that are uninteresting to the customer, such as upgrading a database, cleaning out unused code, refactoring a messy design, or catching up on test automation for old features.”
I hear two common questions when it comes to technical stories:
* How can we write technical stories when user stories are supposed to be user-centric?
* How can we represent technical stories using the typical user story format?
My answer to the first question is that, wherever possible, instead of writing independent technical stories, try to represent the technical requirement as tasks within one of the functional user stories that is reliant on this technical work. Remember to ensure that if more than one functional story relies on the technical work, you factor in the tasks only once and in the story that has the highest priority.
I like the option of including technical work within functional stories (rather than as separate technical stories), primarily to ensure that they don’t get ignored by the product owner simply because they might be “uninteresting to the customer” (Kniberg 2011). By factoring them into a functional story, they certainly can’t be ignored, and the product owner will start to gain an appreciation for some of the technical complexity inherent within stories.
Addressing the second question, how to represent technical stories using the typical user story format, my answer is that you don’t have to. I like the user story format for functional stories, but for technical stories, I find that the format isn’t necessarily fit for purpose. Instead, simply use any format that makes sense and is easily communicated. Ensure that you set a consistent format that is as workable as possible for these technical types of stories. This same advice applies to capturing bugs in the product backlog. Although it is possible to document bugs utilizing the user story format, again, I find that taking this approach can become a bit contrived and confusing (like knocking a square peg into a round hole).
Reference: “Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips”, Ilan Goldstein, Addison-Wesley
Managing the bugs, technical aspects and non-functional requirements is one of the challenges if you use the Scrum framework to support your software development projects. The Agile approaches focus on the delivery of business value to the customer, but there are also tasks that the development team has to perform that are not linked to this goal.
You have to make the difference between some technical or non-functional work that is part of the normal creation and evolution of code, like refactoring or load testing, and tasks that are related only to the infrastructure used by the project. This could be for instance a database upgrade that requires maybe some code modification. The team will need time to perform it without creating any value. These tasks have to be visible to the developing team, but they should not necessarily belong to the Scrum sprints plans or use the user stories format to be expressed. On the contrary, if you have to refactor some code to change a feature, this time should included in the task estimation.
As they lead to the decrease of availability of team members and will impact the Scrum planning, the product owner should be aware of these activities and there might be some discussion on the best way to carry them. The developing team should however have its own specific planning and format to manage these tasks.