Multifunctional Learning & the reusable Sprint Backlog

Have you ever seen a Sprint Backlog that can be reused across Sprints?

I have! A reusable Sprint Backlog contains obvious tasks, for example tasks like ’write code’, ‘make test scripts’ , ‘execute test cases’ and so on. These tasks are too trivial to be useful and undermine one of the fundamentals of Scrum. Let me try to explain why.

 A fundamental of Scrum is multifunctional-learning as described in the 1986 Harvard Business Review paper ‘The New New Product Development Game’ by I. Nonaka and H. Takeuchi. Multifunctional-learning happens when people with different specialities together develop one product and there is no division of labour. That is, all people in the team have to do whatever is needed to get the job done and share the same goal of delivering working product.

Why is multifunctional-learning important in Scrum?

Multifunctional-learning is important because you want a Scrum Team to always be able to make progress in case a team member is absent for some reason. You do not want the team sitting around doing low value work while waiting for the team member to get back. You also do not want to work on low value work while high value work is being postponed. And this often means doing work that is outside a team member’s speciality, hence multifunctional learning is needed.

Why is there a Development Team in Scrum?

Have you ever wondered why there is for example no test role, programmer role or analyst role defined in Scrum? Yes, that’s right… all of the above are everybody’s responsibility. Unfortunately in many companies people work to job title and feel only responsible for the tasks that are within their job description. So, a tester does testing, a analyst does analysis and so on. Having specialised job titles in a team encourages local optimisation. For example, a programmer will tend to locally optimise on his speciality of programming and will work on programming tasks of lower value Sprint Backlog Items (SBI) over woking on analysis or testing tasks of higher value SBIs. I’ve seen lot's of teams not deliver working product at the end of a Sprint because testing tasks were not done. When I asked them what’s going on they responded along the lines of

“the tester will pick up these testing tasks once he is back. He has been on leave a couple of days…”.

The thinking is that the programmer waits for the tester because the tester can do testing work better and faster. A local optimisation decision and as a result the team as a whole is slower in delivering working product.

Does your company sell code?

In Scrum nobody cares that your test scripts are written or that the code is written unless you are in a company that sells test scripts or code. These activities are all essential but not the goal. The goal is to deliver working product. Therefore people in a Scrum team have their main speciality and also learn about one or more other specialities so that they are able to cover for each other when needed to get the job done.

Multifunctional-learning is easy.

A good start is a Sprint Backlog (SBL) that is not reusable. A detailed SBL with small clear tasks makes it easier for team members to pick up tasks outside of their main expertise and help each other. So, instead of a reusable task called 'do analysis, or ’do coding’ you could be very specific about which class, interface, design issues and so on you need to work on. For testing tasks you can be very specific about which test data you need, the test cases to be developed, risks you want to address and so on. Multifunctional-Learning is further encouraged by doing all sessions together. Design sessions, refinement sessions, planning sessions and so on. When people pick up a task outside their speciality themselves they are consciously choosing to learn. The specialist can take on a teaching role and guide people in their learning by coaching, teaching and pairing. So, Scrum encourages optimising the whole instead of optimising locally and a Sprint Backlog that is not reusable is a good starting point.