Shades of Scrum: The Sprint Planning and the pull principle

The Scrum Sprint Planning incorporates the so-called pull principle. The pull principle origins from the Toyota Production System (at least it is he first occurrence I know of) and aims at creating flow while avoiding overload. A processing unit B pulls new work from an upstream processing unit A when B hast he capacity to process it. This is in contrast with the push principle where a planner defines how many items should be processed by time unit and results of upstream processing unit A are pushed into the downstream processing unit B.

In the Sprint Planning the team pulls work from the Product Backlog (the Scrum Guide says that the development team „selects“ Product Backlog Items for the Sprint).

One re-occurring question is whether the team is allowed to deviate from the prioritization – for example when a Product Backlog Item is too fuzzy or when the development team thinks an Product Backlog Item is just bullshit.

The answer is: it depends.

The very first reason fort he pull principle is to avoid overload with its negative consequences (lower quality, burnouts, developers quitting jobs etc.). Therefore it is totally valid to expect the team to pull work strictly according to the prioritization. While older literature is sometimes a bit ambiguous about the „selection“ of Product Backlog Items the current version of the Scrum Guide is pretty clear about that: „The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.“ (emphasis added by me)

But.

Kent Beck once told me that he likes to ask developers if they would invest their own money into the product they are working on. I use this question from time to time when working with teams and I will never forget a larger retrospective at a client where I asked the team exactly Kent’s question: „Would you invest your own money into the product you are developing?“ The team laughed and answered: „We think it would be more valuable to buy Greek government loans.“

That is great feedback for the Product Owner. The team isn’t convinced about the product but it should be (remember the Scrum value „commitment“). The Product Owner should start asking questions: Is the product idea bullshit? Does the prioritization of features lead to weak product while the product idea may be great? Does the team lack the information about the market and users needs to understand the product and the prioritization of features? Working with these questions provides the opportunity to enhance the product a lot. But it requires hard work on the side of the product owner.

A Product Owner who is open for these kinds of discussions may apply the pull principle not only for limiting the amount of work to the team’s capacity but also to the meaning of work. The team would only pull Product Backlog Items into the Sprint when it is convinced that these items are valuable fort he product.

I have seen a lot of confusion about these two types of the pull principle. To make clear what we are talking about we could call the original pull principle „workload pull“ since its motivation is to find the optimal workload. The extended pull principle could be called „purpose pull“.

The workload pull delegates the decision about how much work can be done to the team. The purpose pull delegates the decision about what should be done to the team.

How much?	Pull	Workload Pull	Purpose Pull
	Push	Traditional Project Management	X
		Push	Pull
		What?

Valve (a company famous for its computer games) applies purpose pull on a product level. Developers choose the products they are working on. If a Product Owner has an idea for a new game but is not able to motivate developers to join his project the game wouldn’t be implemented. (see http://assets.sbnation.com/assets/1074301/Valve_Handbook_LowRes.pdf)

Typical open source projects apply purpose pull on the product level as well as on the feature level. Everybody decides for himself on what product to work (and is free to quit whenever he is fed up) and within the product development the developers are free to choose the features to implement.

The following table summarizes the two pull principles:

Workload Pull	Purpose Pull
Create flow of work	Create better products
Avoid overload	Provide meaning for the development team
	Enhance work satisfaction of the development team
Avoid quality problems due to overload	Avoid quality problems due to decoupling of the team from the product

Scrum as a framework supports workload pull as well as purpose pull. (Applying purpose pull to the fullest possible extend would eliminate prioritization by the Product Owner completely and then you leave the Scrum framework). Every project has to determine the appropriate pull level.