Asking the right questions; how to help a Scrum Team switch from a technical to a functional Backlog

Originally published at on February 29, 2016.

One of the biggest challenges for a Scrum Team is to switch from a technical to a functional perspective on their work. The former focuses on the ‘how’ of development — which components must be changed, what code is touched — whereas the latter focuses on ‘why’ and ‘who’ — what do we want to achieve and for whom are we building this software. The locus of these questions lies in the Product Backlog. Assuming that the Product Owner and the stakeholders represent ‘business’ and/or ‘customers’ (which they should), the Backlog should be readable by all. Not only for the sake of transparency, but primarily to facilitate communication within the team and its environment (users, stakeholders). A Backlog that contains purely technical items (e.g. ‘change table X’, ‘rewrite class Y’, ‘extend form Z’) essentially erects a ‘Babylonian wall of misunderstanding’ between the team and stakeholders. It cannot be easily prioritized based on business needs, and can’t be read by stakeholders to get a sense of what’s coming. Although a team with a purely technical Backlog can go through the Scrum-motions without much trouble, it will never achieve the goal of Scrum: Agility.

But getting a team to switch from a technical to a functional perspective is hard for most teams, especially those that are used to a significant distance from the end-user (and the customer). The technical perspective is so much like second-nature for most developers (myself included), that it’s difficult to put on different glasses. In most cases it’s not a matter of ‘not wanting to’, but ‘not knowing how’.

For this reason, I have developed a set of helpful questions that often trigger teams into a functional frame of mind. I often print out these questions on index cards and distribute them randomly among members in the team. Whenever we struggle to define an item in functional terms, members try to answer on of their questions for the item:

  • Why is it important that we implement this?
  • What problem of stakeholders and/or end-users do we solve by doing this?
  • What personas benefit from this, and why? (given that you have personas)
  • How would sales explain the benefits of this to customers and/or users?
  • What reasons would an end-user have to want this?
  • How would you explain this to a colleague who is not part of this project?
  • How would you explain this to your spouse, at home, after a hard of work?
  • What would you show during the review to demonstrate that this is working?
  • If you are a user, how would you test if this works?
  • What changes would a user notice after implementing this?
  • What stakeholders benefit from this, and why?
  • If we wouldn’t do this, what would end-users and or customers miss or be unable to do?
  • What compliment would a happy user of customer give after delivering this?
  • How would you explain this to a potential end-user?
  • What steps would you go through in the application to test if this works?
  • If we’d put this in release notes that will be read by end-users, how would we announce it?

Asking these questions is not magically going to result in a functional item for the Backlog, but if you and your team listen carefully, you should be able to rephrase a technical item into a functional item. Or at least pinpoint the functional purpose of why and for whom you want to do this. And if none of the questions can be usefully answered, then maybe the item has no value at all.

Like what you read? Give Christiaan Verwijs a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.