The Product Development Process of the Enterprise Agility LeSS Framework - dummies

The Product Development Process of the Enterprise Agility LeSS Framework

By Doug Rose

At first glance, the LeSS framework graphic makes LeSS look a lot more fun than other enterprise agility frameworks. It almost looks like a theme park map. People appear to be standing in line at concessions booths. Some are juggling. Two people are even riding a teeter-totter! You can almost smell the popcorn.

LeSS framework enterprise agility
Copyright © 2014–2017 The LeSS Company B.V. Used with permission.
The LeSS framework.

On closer examination, you begin to see the LeSS product development process in action surrounded by a half-dozen key concepts.

LeSS is based on the premise that Scrum is all an organization needs for individual teams to deliver quality products fast. However, it recognizes that some large enterprises don’t have a culture or ability to deliver products with only one or two small teams. For them, LeSS is a good compromise because it creates a balance between concrete practices and the ability to inspect and adapt.

Smack dab in the middle is the LeSS product development process, which begins on the left and continues indefinitely off to the right with three-dimensional structures shaped like arrows to point the way. Product development comprises a never-ending series of sprints, so although the process appears linear, it’s actually circular and continuous. Imagine curling this page over so that the “Next Sprint” overlaps the “Previous Sprint,” and you’ll understand. As soon as the Scrum teams complete a sprint, they start another sprint in a continual process that improves product value.

However, each sprint is linear with a clear starting and ending point. It begins with a product owner and product backlog and ends with a potentially shippable product increment.

Product owner, product backlog, and sprint planning

On the left side of the LeSS product development process is the product owner and product backlog. The product owner selects features from the backlog and engages in a two-stage sprint-planning process:

  • Sprint Planning 1: The first stage of sprint planning centers on determining which items in the product backlog to work on and setting a goal for the sprint.
  • Sprint Planning 2: The second stage of sprint planning involves determining how to get the work done — how to complete the selected items from the product backlog.

In other words, Sprint Planning 1 is about what to do, and Sprint Planning 2 is about how to do it.

Sprint backlog

One of the objectives of sprint planning is to develop a sprint backlog for the various Scrum teams. The sprint backlog is depicted as the Jumbotron that all the team members are looking at. Each team draws items from its backlog and then works to complete those items in time allotted for the sprint.

Scrum teams

Over the course of a sprint, Scrum teams pull one or more items from the product backlog and work on completing them over the sprint. To complete their tasks, Scrum teams must collaborate with:

  • Customers and end users to refine the definition of the product backlog item
  • The product owner to prioritize product backlog items
  • Other teams to coordinate and integrate their work to produce one whole product increment

Note that the teams are divided into three lanes with a product owner who spans all three lanes. The product owner is about as close to top-level management as you will get in LeSS, and it’s really not management at all. The product owner simply organizes the work to help the teams complete their sprints.

Scrum Masters

You may notice that the three teams have only two Scrum Masters (designated by “SM”). One Scrum Master works with the two teams in the bottom two lanes. The other has her own team in the top lane. This shows that unlike team Scrum, LeSS permits different teams to share Scrum Masters.


The double-headed arrows that cross the lanes dividing the teams represent the coordination required among teams to develop a single, unified potentially shippable product increment that’s ready for shipment.

Daily Scrum

The dialogue bubbles in the graphic represent Daily Scrums. Every day, each team meets (without managers or a Scrum Master) to answer the following three questions:

  • What did we do yesterday?
  • What will we work on today?
  • What is in OUR way?

Teams may meet together during Daily Scrums to spend some time coordinating their work.

Product backlog refinement

Teams are required to spend some time during their sprint (less than ten percent) to refine the product backlog for future sprints. Refinement (depicted by magnifying glasses in the graphic) may include one or more of the following:

  • Splitting big items
  • Adding detail about an item
  • Estimating the time required to develop an item

Note that the teams in the top two lanes share a backlog refinement meeting. While in the bottom lane the team has its own meeting.

Sprint review, retrospective, and overall retrospective

At the end of the sprint, various groups meet to discuss the outcome of the sprint and ways to improve the product and process:

  • Sprint review: The teams, product owner, end users, customers, and other stakeholders meet to discuss what the team built along with changes and new ideas to decide the direction of the product. This is where each team demonstrates its work. You can see the little signpost on top of that meeting. That represents the feedback that the team gets so team members can inspect and adapt their product.
  • Retrospective: Team members meet to share information and insight and discuss ways they can improve their work going forward.
  • Overall retrospective: All teams meet with the Scrum Masters and product owners to discuss much broader process improvements, overall organization, and systemic problems within the organization.

Potentially shippable product increment

Every sprint ends with a potentially shippable product increment. Prior to that, during the sprint, the teams must collaborate to integrate their work and produce a whole product. The overall goal of developing a potentially shippable product increment is intended to:

  • Keep the focus on the whole product
  • Increase transparency and eliminate the possibility that any portion of the work remains undone
  • Reduce work in progress
  • Maintain short feedback cycles for continuous improvement

At the end of the sprint, you have a potentially shippable product increment, but that doesn’t mean everyone stops working. As soon as the final review process is over a new sprint begins.