/A lean thinking perspective of scrum
lean methodology agile

A lean thinking perspective of scrum

lean methodology agile

ARTICLE – This piece analyzes the different elements of scrum, an agile software development framework, as seen from the point of view of traditional lean thinking.

Words: Rodrigo Aquino, IT Coordinator, Lean Institute Brasil

Scrum is a development process based on iteration and incremental improvements that was initially created for managing software projects. Many of its features can be compared to lean principles and tools, however, and I believe that understanding this relationship is fundamental to help us align software development with the company’s strategy and, in the process, generate more value for our customers.

The main idea behind scrum, which differentiates it from the waterfall model, is providing a number of deliveries throughout the process of designing software. This way, the development team receives continuous customer feedback on smaller and more manageable parts of the end product and can improve them (and learn) by means of small PDCA cycles.

The concept of scrum was developed in the early 1990s by Jeff Sutherland, with John Scumniotales and Jeff McKenna, and by Ken Schwaber – who used this framework in their software companies and paved the way for its spread across the software world.

The following figure (courtesy of Joost van der Schoot – http://vdschoot.com/agile/scrum/) shows all the stages of the process and the interactions between those involved:

scrum aquino

Let’s now look at some of the main components of scrum from a “traditional” lean perspective.


  • The product owner (PO) represents the client in the company that is developing the product. This person is responsible for developing and keeping a Product Backlog (a very detailed document listing every product requirement), to define priorities within the development process, and to negotiate every possible adjustment along the way.

From a lean point of view – The figure of the PO represents a clever way to speed up the flow of information between the customer and the developers. This reduces the risk of rework that so often appears in non-scrum development projects. A very important lean concept, which could be related to the role of a PO, is genchi gembutsu (“go see”): knowing the customer well and ensuring that, at the gemba, the development team is working on the correct product feature and to customer specifications is critical to the success of any initiative.

  • The scrum master (SM) is the leader of the development team and establishes the relationship between the developers and the PO. Their role includes removing barriers hindering the team’s progress (for example, internal conflicts) and involving the infrastructure department should any hardware component stop working.

From a lean point of view – People are key to the success of an organization. Lean teaches us that each leader must be in constant contact with his team and know each member well enough to understand the problems they encounter each day. This enables flow and therefore customer satisfaction.

  • The scrum team is the group of people who develops the product, ensures its quality is top-notch, and takes responsibility for delivery to the customer. Although they have a leader, the team should be self-manageable and multifunctional. Literature widely suggests that the number of people for a scrum team should be between five and nine. In his presentation at last year’s Lean IT Summit in Paris, Jeff Sutherland said that, in his opinion, an ideal team should be made up of five people.

From a lean point of view – Having cross-functional teams, lean tells us, allows for a quick flow of information, because waiting for the contribution of a team member from another function doesn’t happen. Lean Institute Brazil has been training people for over 16 years and we tend to recommend that teams (for example to complete a value stream map) do not exceed seven members.


  • Sprint planning meeting (eight hours): the Scrum Master, team and PO participate in this meeting with the aim to devise a Sprint Goal (the delivery of a functioning piece of software) and a Sprint Backlog (the list of backlog items the team will deliver). Poker cards are commonly used to assign points to each user story or task, to understand how much time and resource developing it will take – each member chooses a card with the number that best indicates the amount of effort required. Sometimes it is necessary to play a few rounds to get enough repetition of a certain amount of points. It is important to never use averages, but the estimate that was picked most frequently.

From a lean point of view: Meetings can be a huge waste in the process. Therefore, it makes sense to have a Scrum Master who makes sure that everyone is making the most of the time allocated for the meetings and not losing focus. In lean organizations, stand-up meetings are normally led and facilitated by one person. Another parallelism with the lean philosophy is represented by the fact that the people doing the work are asked to estimate (with the Poker cards) how long it will take them to complete it – no one is better suited to estimate how much effort a user story (a description of a feature of the product as seen by the user) or task will require than the people performing the work. This is a critical teaching of lean thinking: people must be empowered to solve problems and improve the work, because they are the ones who are closest to the process.

  • The daily meeting (15 minutes) is held at the beginning of the workday and sees the involvement of the whole team. All members stand together and answer a number of questions: “What did I do yesterday?” “What will I do today?” and “What problems prevents me from continuing with my work?”

From a lean point of view – In their 2008 book The Toyota Product Development System, Jim Morgan and Jeffrey Liker talk about quick and frequent meetings, which in this context are used to determine whether the project is going as planned. This ensures that potential problems are found quickly and solved readily.

  • Review of sprint (up to four hours). The SM, team and PO participate, with the objective of delivering a working part of the final product. If necessary, others involved in the project (such as the client) can participate. The objective of the review is to assess the product feature against the sprint goal.

From a lean point of view – A checklist should be managed by the PO in order to make sure everything is done according to client needs. In lean thinking we often talk about making sure that all information is “complete and correct” going forward.

  • The sprint retrospective (up to 3 hours) occurs between the SM and the team with the objective to evaluate what happened during product development and to understand how to do better in the future.

From a lean point of view – In  lean, the term used for this type of activity is nemawashi, which means “reflection.” The spirit of kaizen should always be alive within a team.


  • The product backlog is a collection of the user stories that will make up the product. Each user story can contain one or more features to be delivered to the customer. From a lean point of view – This can be considered as stock of information (inventory is the biggest of all wastes in lean), which should be reduced to get as close as possible to continuous flow. Batching information will make us more vulnerable to rework and less responsive to changes in demands in the market.
  • The sprint backlog is a specific list of tasks that team has to perform to deliver the part of a product to the customer. In this context, one user story can turn into one or more tasks.

From a lean point of view – Dividing the user story into smaller tasks will make it easier to find a solution and expose problems. This is one of the main lessons lean teaches us: breaking down a problem and analyzing each part will allow us to get to its root cause.

  • A burndown chart is used to verify progress and the track the actual and estimated amount of work in a sprint. It helps scrum teams to determine whether a sprint goal is to be met. This graph should be updated daily so that decisions are made in relation to what must be achieved. There is also something called a task board that clearly shows what each team is developing.

From a lean point of view – One of the greatest lessons of lean thinking is to make the work as visual as possible. This approach will help to create error-proofing mechanisms known as poka yoke.


Understanding the relationship between frameworks is very important, and there is no doubt scrum and lean thinking have a lot in common (as demonstrated above).

Scrum is helping many companies around the world to eliminate waste in the development phase of various types of products (mainly software). I think its most successful feature is perhaps the fact that it creates an environment in which people are valued and engaged, which happens to be the core message of lean thinking.

It is my hope that this article contributes to increasing mutual understanding between the scrum and lean communities, and to proving how compatible (complementary, even) the two are.



Rodrigo Aquino photograph

Rodrigo Aquino has worked in I.T. for 16 years. He holds an MBA in Software Engineering at University of São Paulo and is a graduate in Computer Science at the Pontifícia Universidade Católica de São Paulo. He’s held the role of Coordinator of Information Technology at Lean Institute Brasil for over three years. He has worked with organizations including ICEC, Totvs, Wunderman, and Petrobras.