In SCRUM, business requirements are illustrated in what we call user stories. They basically capture who, what and why. However, we focus too much on ‘who’ and ‘what’, but ‘why’ is critical to understand their relevance. User stories usually look like:
A proper definition is given by Martin Fowler, pioneer of agile methodologies:
User stories are a chunk of functionality that is of value to the customer.
Functionality, that’s the word. User stories should be written in business language by the end user’s ambassador, a.k.a, the Product Owner. Therefore, they must be functional and state clearly what it is expected – not necessarily in detail but in purpose.
Nonetheless, we often feel the need to create user stories such as: “As a developer, I want to refactor X module so that it improves performance of the whole system“, which is a clear example of a task with no direct value to business .
In my opinion, this sort of tasks should not be catalogued as user stories and cannot even be in the product backlog. Technical user stories are tasks who should be left to the development team and out of the SCRUM process. But, don’t get me wrong. Technical tasks are always required. Actually – lean thinking – they are “Non-Value-Added but Necessary” work. It’s just that, sometimes, we forget SCRUM is product-oriented.
Finally, the best thing for me to do is to translate them into something functional. If it’s not possible, explain who may benefit from its implementation from a business point of view. That’s it. So, how do you manage technical tasks in SCRUM?Antonio González