Category Archives: Lean

10 (understated) Lessons from TPS!

There is a  lot of of literature on application of  Lean and TPS to software industry. The Kanban Method takes the majority share of discussion around this. However, there are some key takeaways from Lean thinking that need to be understood/appreciate but haven’t got adequate focus in the software community. This article puts into perspective some of these learnings from TPS and what it means for us in the industry.

The Production Pyramid:

Production Pyramid is basic of a Toyota Production System. There are many variations of it in the public domain. However, one of the versions that I was introduced is this:


Production pyramid has some key insights for us.

Lesson I: Getting the foundation right!

The foundation of any improvement starts with 5S activities. As we get better, we focus on existing wastes (the 3MUs) and supplement them with Visual Management methods to improve our process.

Lesson II: Be patient to get the foundation right!

There is no direct co-relation between the final objective of Profit and these foundation activities. Yet, without putting into place a strong foundation, any expectation of sustained profit is misplaced.

Corollary: When organizations focus on short term profits (monthly or quarterly), they will often drive themselves to ignore these foundation activities, causing them long term negative impact.

Understanding 5S Better:

One can refer to Wikipedia for a more detailed elaboration of 5S. However, for the purpose of this article, I will summarize the same:

  1. Seiri (Sorting): Sort articles into necessary/unnecessary categories; remove those that are not needed
  2. Seiton (Orderliness): Necessary articles at necessary time; you should be able to take out any article at any time.
  3. Seiso (Cleaning): Inspection to find abnormalities, keeping ergonomics in mind
  4. Seiketsu: Maintain a clean state (that you have got from the above 3S)
  5. Shitsuke: Develop the habit of abiding by what is laid down.

Lesson III: 3S vs 2S

It is important to recognize that while the Top 3S help to get better using Kaizen, the Bottom 2S help us to sustain the gains from the Top 3!

Continuous practice of these activities should be a part of the team habit/culture; not an afterthought from some corrective action or a senior person pushing the team to move in this direction.

While there are a lot of areas of application of Seiri, Seiton and Seiso in the manufacturing sector, there are some impacts areas for us in the software industry, though exactly not in the same buckets. Some of these, but not limited to, are:

  • Technical Debt: there are many things that contribute to technical debt and one needs to focus on all of the same
  • Workplace hygiene: once again, there are many things that fall into this bucket and team should focus on them
  • Standards/guidelines for design, development, etc. The importance of this extends to naming conventions, folder structure, etc.
  • Information sharing across teams using notice boards, portals, team meetings, etc.
  • Right infrastructure for the team/job profile, including hardware/software/other resources
  • Clear role/responsibility definition with person identification
  • Inspection to find work product abnormalities, be it for code/test cases/design documents, etc.

Many of these would also get repeated when we focus on removing Muda. There is already a lot of literature on the same in the public domain that I am not repeating.

Lesson IV: Three stages of Seiso

There are 3 stages of the Seiso process that can be well adapted to the software development:

  • Start off with the actual fixing work (defect fixing, design fixing, test case fixing, infra fixing, etc.). In other words, focus on “resolution”.
  • Kaizen the process of fixing – how can this be improved itself?
  • What can we do so that this “fixing” can be eliminated? In other words, focus on “prevention”.

Software professionals from the CMMI background are well familiar with Corrective Action and the DAR process area. It isn’t hard to recognize the similarity between the two.

This 3 stage process can help teams go much beyond just the “fix”. In most development teams, the urgency to “fix” things prevents the team from getting deeper into the next 2 activities. Its counter-productive in the long term!

Lesson V: Keeping a “clean” state

Seiketsu is about how to keep a “clean” state! Its analogous to keep a level of code quality once it has been achieved. Traditionally, project teams have been weak in this. We have a large Testing phase to clean the code only to see the code quality go bad in the next Development phase; then, we again hit the Testing phase.

Agile thinking, with its associates engineering practices (TDD and CI) focus on this specific aspect. One cannot really be Lean or Agile without these engineering practices.

Lesson VI: Using Visual Management when abnormality is detected

The other aspect of Seiketsu is to use Visual Management methods to alert teams when abnormality is detected. This is analogous to a build failure that gets notified to the team participants immediately for attention and resolution! There may be many other points of failure that the team would like to focus on visually. Kanban Boards have 2 such examples: a) Lanes on a Kanban Board getting highlighted in RED when WIP limits are exceeded is one such example b) A card that is not able to flow forward getting highlighted using Blockers. A project teams should identify such points of failure/abnormality and define visual methods to highlight the same.

Lesson VII: Implementing Shitsuke

Implementing Shitsuke is done in the following 3 stages:02

  1. Decide what needs to be defined; make others aware of it
  2. Follow the procedures; make everyone follow it
  3. Confirm if the procedures are being followed; appreciate the people who are following it and guide the people who aren’t.

Lesson VIII: Improvement initiatives are harder to sustain

It is also well acknowledged that while one time improvement initiatives are doable and achievable, it is lot harder to sustain these initiatives and get them absorbed in the team DNA. In other words, of the 5S, the latter 2S is much harder than the former 3S. If not sustained with persistent effort and management focus, the benefits gains from the first 3S fades away over time.

Lesson IX: Keep broadcasting your success

Once your succeed in reaching a milestone of process improvement, share it with others and talk about it. Obviously, it motivates the team and helps them gain recognition for the good work they have put in.

What isn’t obvious is the phenomenon that happens when you continue to display the results! If the results do come down for some reason, the team is strongly motivated to set it right. Its embarrassing to fail on something that you have just been acknowledged for!

Lesson X: Kaizen vs Sustenance

This brings us to the most important learning – while Continuous Improvement is important, the team needs time to sustain and internalize the improvements from the earlier Kaizen cycles. My experience is that this is where many teams fail!

The importance of this alternate cycle between Sustenance and Kaizen is understated in current Agile/Lean literature in IT (to the extent that I have read). We keep reiterating the importance of Continuous Improvement. It is assumed that once a good practice is identified, it will be adhered to over time. In reality, it is much harder.

In the Kanban Method, we talk about the importance of Defining Policies. While that definitely moves in that direction, there is more focus needed to sustain.

Maintenance/Sustenance means setting standards and carrying out activities as per the standards. One typically undertakes a SDCA (Standardize, Do, Check, Act) cycle in this phase. A team needs to develop Standards/SOPs/Checklists to help the team follow the same and stabilize current practices and methods.

Kaizen means to set targets higher compared to current standards and then carry our activities to make it happen. One typically carries out the commonly understood cycle of PDCA for this.

A team needs to move in alternate cycles of Kaizen and Sustenance. Without this, any gain is temporary and it fizzles over time.


Kaizen leads to newer practices and methods that need to be standardized and internalized by the team BEFORE the next cycle of kaizen improvements are brought to the team.

So, don’t just focus on improvement… keep stabilizing and improving!

I want to end this blog by acknowledging Norio Suzuki for his inputs and helping with my deeper understanding of Lean and TPS.

Applicability of Agile/Lean/Kanban Methods for fixed scope/budget projects (with short duration)

The Pune Chapter Meet of the Limited WIP Society was held on Mar 8, 2014. This session objective was to address challenges faced by Lean-Kanban practitioners in their projects. Participants from 4 different organizations attended this session. A couple of problems were posed by the participants (Meetup Link) ahead of time. We decided to work on the first one for this session.

Problem Statement: Some projects are fixed scope, fixed budget and have relatively small duration – 3-4 months. In this case, would it make more sense to go for: a) Pure Critical chain or Microsoft project plan based date based approach b) Combination approach: Critical chain based planning followed by Kanban execution. c) Pure Kanban flow based execution approach with no date based plan for individual stories.

The team started the session by working in teams to identify what aspects of Lean/Kanban facilitate small project execution that have fixed scope, fixed budget and small duration (“+ives”) and what aspects don’t (“-ives”).01

Next, they came to the white board, brought all their points and grouped them together. The result looked something like this!01

Result: The team, working independently, had identified 18 positives vs 14 negatives in adapting Lean/Kanban/Agile principles to fixed scope, fixed budget projects with a short duration That a very positive reinforcement of their suitability. Therefore, Option C was taken as the way forward for the rest of the session.

While the session started with a focus on projects with short duration, it was evident that except for a couple of points, this discussion was valid for project of fixed scope/budget, independent of any duration.

The following Positives were identified when applying Agile/Lean methods to these projects:

Positive Contributors


  • If using SCRUM, defined planning activity
  • Small Cycles
  • Estimate upfront (high level) and understand the feasibility of delivering
  • Divide into stories; complete logical business flows
  • Can help in sustainable pace


  • Higher Quality Delivery
  • Stable Software
Scoping and Prioritization:

  • Early Start of mature (well defined items)
  • Focus on prioritizing – very relevant
  • Principles of Agile help; focus on blockers
  • Power visualization

Early Feedback

  • Still relevant
  • Demos are confidence building


  • Team empowerment is positive
  • Collaboration
  • Encourage small team size
  • Cross functional teams

After a brief discussion on the positives, since the positives were stronger than the negatives, the focus on the remaining session was how to mitigate the negative factors in these projects.

The group decided to focus on the negative contributors. Each group was given one of the negative areas to focus on. They were asked to break up the negative contributors to the next level (identified as LI below) and identify possible resolutions for the same. Then, all teams converged and refined the possible resolutions in each of the areas. The following negative contributors were identified with a clear path to resolve them.

Negative Contributors
Planning Area:  01
Negative Factor:MSP is used for Portfolio and Program Planning..Resolution Approach: Lean Methods exist for Portfolio Level Planning, like Portfolio Boards. We need to educate that it a myth that Agile = No planning.
Hence, training, education and pilot programs need to be considered as a means to bring about awareness on the importance of planning and the methods available.
Negative Factor: For such small projects, the team might have good visibility of the scope. Budget, scope and timeline for such projects are often well defined. Hence, they might be tempted to plan heavily upfront and execute based on that..Resolution Approach: High level planning is good and if the details are available and if everyone feels assured about it, then doing isn’t a negative. Avoid detailed estimation, planning to man hour level and then getting into variance tracking. This will lead to timelines getting met at the expense of quality and work-life balance. Negative Factor: In a very dynamic environment, MSP helps in quick impact analysis..Resolution Approach: This is not accurate. With MSP, the defined path was cumbersome. One would find the critical path, then do all kinds of jugglery like fast tracking, crashing, etc. It was based on estimates and we all understand that estimates are dead on arrival!So, we need to move all stakeholder discussions to velocity/throughput centric discussions. To enable this to happen, a lot of training needs to happen for all stakeholders involved.
Negative Factor: No Dates; hence, things pile up.Project Manager does not get sense of delays; lack of timeline; project delivery date is variable..Resolution Approach: The obvious answers the team came up with was to have time boxes (what SCRUM does). Also, it was discussed that Kanban does not have anything against Due Dates. In fact, many Kanban team use Due Dates. The risk is that Due Dates should not construed as milestones that puts pressure to finish the job, no matter what.
Resource Management:  01
Negative Factor: MSP helps in Resource Planning, Capacity Planning..

  • Cards pile up in the end; no flexibility to take care of scope uncertainity.
  • No targets for SWP; ST is not able to plan testing
  • Sudden resource requirements that come up case disruption to the whole project
Resolution Approach:

  • The best way forward is to have stable teams. However, if this is not possible in a given environment, we should be able to visualize this constraint and give time to stakeholders to plan resources. The way to do this is document in this blog.
  • Another approach is to under-allocate critical resources. They are often called in to help others or take care of some critical work in the pipeline.
Testing:  01
Negative Factor: One has to test repeatedly, specifically regression. Since the project duration is short, the tendency is to test at one shot in one batch.Assumption Testing and development are being done by 2 different people..Resolution Approach: Automation
Where automation is not practical or feasible for whatever reason, the team felt that right documentation or Knowledge Transfer to the tester can help reduce repeat testing. If the tester understands the scope of each user story well, then he can focus on the scope of that user story and in subsequent test cycles, focus on scenario based testingIn a specific environment where ST is expected to “Certify” the product quality and hence, need to re-test “all” test cases, including unit level test cases, the recommended approach is to focus on reviewing the comprehensiveness of the Unit Test Cases and Unit Test Results. That would help Dev teams get better by not taking Unit Testing lightly. By ST doing unit level testing, it makes Dev teams continue with their current practices.In cases where Dev teams are mandated to Junit testing, ST teams can seek the Junit Code Coverage data to understand the level of comprehensiveness of Unit Testing.
Env/Infrastructure:   01
Negative Factor: The team identified Configuration, Sanity, Missing HFs, Connectivity, Overloading of environment as all related issues to environment, infrastructure..Resolution Approach:

  • Environment/Infrastructure planning cannot be a batch mode process. Just like capacity planning, Env/Infrastructure needs to be continuous process. Whenever a card gets prioritized within the backlog, all its environment and infrastructure needs can be defined on a card and put in a parallel swim lane to track them to closure (see screen shot)
  • Get people from the Infrastructure/ Environment teams involved in the Sprint planning process; if you are following the Kanban method, pull them in whenever Backlog grooming happens.


Pareto Analysis of Blocked Cards

The role of metrics in TPS is crisply explained in Jeffery Liker’s book “The Toyota Way”. He explains that Toyota prefers simple metrics and does not use many of them at the plant or the company level. Some of my peers may be surprised to hear this!

The author highlights his point with a simple example. During one of his visits to one of the Toyota plants, he was told that apart from a few basic metrics (like cost of plant operations, parts per million defects, some safety related and productivity), the metric Toyota finds most useful as a manager is the number of “Andon” pulls made by each Team Member to stop the production line. They regularly graph this data, noting the problems that caused the Andon pulls and use Pareto Analysis to identify the most common reasons. They take corrective measures to address these reasons. The VP of this manufacturing unit explains how “this metric provided great insight into the actual day-to-day problems faced in the production process”.

The analogy to this in software systems that use the Kanban Method, is the blocked card. Most of us who have been working using the Kanban Method have experienced that blocked cards are a big impediment to smooth flow, increasing WIP counts and cards getting stale.

If you have a physical board, it would be difficult to track this manually over time. We, in SwiftKanban (, have built functionality to track this, though I would personally prefer a two level categorization.


However, not all tool providers have done even this. So, the question is: are you doing an analysis of the reasons for having Blocked Cards in your Value Stream during your retrospectives? Are you putting a corrective action for the same? I suspect that teams are missing a significant potential for continuous improvement by not doing a Pareto Analysis of Blocked Cards.

I would like to hear from the practitioners how frequently they are doing Pareto Analysis of blocked cards and then defining action items during a retrospective to fix them. If you have a physical board, are you doing it manually? Look forward to your response…

Capacity Planning for Dynamic Teams following Kanban Method

1.    Abstract

Projects are often executed by dynamic teams. They start with a small core team and as the project gains momentum, add resources over time. This is commonly seen in IT service organizations that do fixed price projects. Fixed price projects have a defined scope that needs to be delivered within a contracted budget and within a negotiated timeline. For the purpose of this experience report, “Dynamic teams” or “Fixed Price projects” will be used interchangeably.

Unfortunately, as Ron Jeffries put it, “Agile is founded on management of scope, not predicting when you’ll be done, even if you had fixed team size and “fixed” scope.”

Yet, a significant portion of the software development community does want to adopt some of the Agile/Lean principles that they believe they will benefit from. For example, they see value in making smaller and faster releases to their customers to get early feedback and de-risk their project. They see value in better team interactions that can motivate people to take greater ownership.

However, one of the key assumptions in Agile is about stable teams. Stability in teams is important, both from the perspective of size and composition. Stability helps achieve self organizing teams. Stable teams make forecasting possible based on Throughput (or Velocity) of the team. If the team is not stable, one cannot use the current team’s Throughput as the basis for forecasting when the backlog and the work-in-progress(WIP) will be completed.

This makes it difficult to ask a very common management question in such projects: How many resources are needed to get the defined scope done within the negotiated timeline? Further, if there is Scope Creep, how does this impact the schedule or the resources plan? This Experience Report, based on the author’s experience in applying Agile/Lean principles to dynamic teams or fixed price projects, lays out an approach to answer these questions.

It must be highlighted that these questions and some of the approaches suggested seem contrary to well understood Agile thinking. For a true Agile practitioner, these are not the right questions to ask. However, these are questions that managements or customers will ask when they need a defined scope within budget and negotiated timeline; yet, adopt some of the Agile/Lean practices to benefit from the same.

2.    Stages of Capacity Planning

Capacity planning is done across the project life cycle:

a)    At the beginning of the project when a Resource Plan is made.

b)    During execution of the project:

    1. As the project is executed, changes happen. Things don’t go fully as originally thought off, resource changes happen because of attrition or other business priorities, etc. This calls for a defined approach of how and when Capacity Planning should be done.
    2. Further, as the project is executed, Scope Creep happens. Agile teams are expected to welcome scope change. However, when one is executing a Fixed Price project, a re-assessment is needed to find out whether the committed timelines and budgets can be maintained with the allocated resources. If not, then a dialogue with the customer is needed to converge on the revised scope/budget/timeline.

In this Experience Report, we will look at how to do Capacity Planning for each of the above situations. This report uses the Kanban tools to illustrate with examples. However, the same approach can be applied if one I executing a Fixed Price project using the SCRUM approach.

3.    Capacity Planning at Project Beginning

Capacity Planning for a team at the beginning of the project is meant to address the key question – how many resources, and of what profile, do I need to deliver the defined scope in the given time? The method to answer this question does not change compared to how one would do it traditionally.

The approach is as follow:

a)    Identify the EPICS. Decompose them to MMFs and User Stories.

b)    Once the User Stories have identified, make a high level resource capacity plan based that details the skill profile needed for each of the User Stories. One can then aggregate it the capacity plan across user stories by skill profile. So, an example of an output from such a planning process would look like this.


Once a detailed plan is made, it can be aggregated across user stories by skill profile as follows:


Such a Resource Plan will give management the confidence to deliver the defined scope within budget and stated timeline.

Once project starts, things don’t always go as per plan. This is why Capacity Planning needs to be done regularly. In the next stage, we use the Kanban Method to show how this can be accomplished.

4.    Capacity Planning during Project Execution

While an original plan is established, things start deviating from plan shortly thereafter. This is one of the reasons by many Agile practitioners discourage detailed planning (as illustrated above) in the first place.

Nevertheless, having established the need for the same in applying Agile/Lean methods to Dynamic teams, the next question to answer is – how and how often do we keep re-looking at this resource plan? We use the Kanban Method to answer this.

Below is a Board layout for the Backlog before cards get taken for Development. You will notice that this is split into 3 sub-lanes: a) Pending b) Next Priority c) Ready for Development. The Cycle Time for cards moving from “Next Priority” to “Development” should be around 1 month. The Cycle Time for cards moving from “Ready for Dev” to “Development” should be around 1 week.


In the next step, we use Explicit Policies to do Capacity Planning during Project Execution:

a)    For the “Pending” lane, define a policy that states “Before exit, validate resource demand for the card”. This implies that whenever a card is moved from “Pending” lane to the “Next Priority” lane, the team will re-visit the Capacity Plan for that card (as laid out in Step 1) and highlight the needed resources to the Project Manager. If resources are not available, then the card is Blocked and kept in the “Pending” lane.

This approach highlights the team management of any potential resource constraints at least 1 month ahead of time.

b)    For the “Next Priority” lane, define a similar policy – “Before exit, validate resource demand for the card.” If resources are not available, Block the card.

This approach helps identify any resource constraints due to last minute/unplanned events. It helps reduce the probability of cards getting stuck in development because of resource issues subsequently.

This process would happen for each card whenever it is moved from one lane to next, often during Backlog Grooming.

A few additional points to be highlighted:

a)    Have a narrower WIP limit as you move from left to right within the Backlog stage. This will help in cards flowing to downstream lanes if some cards in the upstream lanes are blocked for resource constraints.

b)    When assessing the resource availability in the above stages, take into account the cards that are already in progress with their current Due Dates.

5.    Capacity Planning for Scope Creep

Agile projects accept scope changes by continuous re-prioritization of the backlog. Teams continue to be undisturbed, even when Scope changes. That is not the expectation in projects that are executed in the fixed price environment. Scope changes are executed using the Change Control process. A Project Manager has to assess the impact of Scope Change on the already committed timeline and budget.

Agile methods make this remarkably simple. If you are following the Kanban Method, the team already has the Throughput data. If the current Throughput is applied to the revised scope, the revised timeline can be easily determined. This is done with the Cumulative Flow Diagram (CFD). Let us understand this with the following example:

The images below show a Board and it’s corresponding CFD diagram.



This CFD shows that for the team to complete the backlog, they need to complete the Value Stream at the 16.13 story points/day.

Now, let us consider a situation where because of Scope Creep, new cards have been added to the Backlog to the extent of 120 story points. These “new” cards are highlighted in red in the Backlog lane.


When CFD is plotted now, it shows the following data:


This shows that the desired Throughput to accomplish the revised scope within the same timeline increases from 16.13 story points/day to 18.09 story points/day, an increase of around 12%.

Once this is identified, the information can be shared with the stakeholders to discuss and evolve the best way forward. Resources could be added to the desired extent (subject to availability) or one could do scope substitution or a combination of both. Worst case, all stakeholders know that at the present Throughput, the revised scope will mean extending the timeline by 12%.

A similar exercise using traditional methods/tools would take an extended period of time. One needs to do a combination of resource loading and balancing, re-identifying the critical path, fast tracking or crashing to shrink the critical path tasks before they can conclude on the impact to the overall project timeline and budget.

6.    Summary

Capacity planning is a challenge for dynamic teams that want to adopt Agile/Lean practices. This Experience Report shows that the approach for building the initial Capacity Plan is unchanged whether the project is delivered using traditional or Agile/Lean methods. However, during project execution, using the team Throughput or Velocity, the Capacity Planning process becomes much simpler and accurate.

Learning Agile Requirements with User Story Mapping

The Limited WIP Society Bangalore Chapter held its 2nd Meetup at Pune on Oct 26. The session was hosted by BMC, India and their office. A group of about 25 Lean/Agile enthusiasts met on this Saturday morning.As in the last Meetup in Bangalore, the focus of this Meetup was also Agile Requirements and for the same reason – it is hard to establish flow and reduce cycle time when requirements are not independent, small or testable. Our experience shows that using traditional requirement definition approach, we get a set of highly inter-dependent requirements that get stuck at System Testing, waiting for each other.I started the Meetup with a detailed presentation on Agile Requirements. We discussed about the problem with requirements written the traditional way, how User Stories mitigate that problem, how to decompose User Stories and finally, doing User Story Mapping.Post a short tea break, the group was divided into 2 teams. A case study was given to both the groups. The groups were asked to first identify the sequence of steps defined above. After about 90 min of intense discussions within each of the groups following the 3 step process, both teams had their first version of the User Story Maps, though not complete.Once the User Story Mapping was completed, we discussed how to do Release Planning using the User Story Map. A follow-up question was about User Story estimation. The group was introduced to the Planning Poker approach. The Meetup ended with a quick summary of the session and a retrospective of what worked well and what could be improved in the next Meetup.



Applying WCM to the Software Industry

I recently spoke at Symbiosis University on how WCM (World Class Manufacturing) thinking is being applied to the software industry.  World Class Manufacturing [WCM] is the collective term for the most effective methodologies and techniques to realize the objectives of: A) Products of consistent high quality B) Delivery on Time of the desired quantity and C) Product at the lowest cost. The commonly knows WCM methodologies and techniques are TPM, Kaizen, TQM, Six Sigma, JIT, and Lean Manufacturing. This presentation shares how the software industry has been adopting many practices from the above techniques over the last decade. 

Agile Requirements with User Story Mapping

The Limited WIP Society Bangalore Chapter held its 3rd Meetup at Digite’s Bangalore office. A group of 20+ Lean/Agile enthusiasts met on Saturday morning at 10am.

The focus of this Meetup was Agile Requirements. This topic was chosen because it is hard to establish flow and reduce cycle time when requirements do not follow the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small and Testable). Using traditional requirement definition approach, we get a bunch of highly inter-dependent requirements that get stuck at System/Integrated Testing for each other.

I started the Meetup with a small introduction to the need for Agile Requirements. Post this session, Manik Choudhary, Agile Project Manager at SAP Labs, started the main session. He gave a high level overview of the larger landscape – building the product vision using Lean Canvas, using Design Thinking to validate your concept and then use a technique like User Story Mapping to build the product backlog.

With this high level view, he started with the basics of User Story Modeling. This was done in 3 stages. First, identify the vision of the product by defining the usage sequence of the product. Next, identify the Personas who will use the system and how each of those personas will use the product in the above Usage Sequence. This is the “backbone” of the product. Finally, define the user stories under each of the usage steps (within the usage sequence) for each of the personas.

With that overview, the team started the workshop. The group was divided into 2. A case study was given to both the groups. The groups were asked to first identify the usage sequence. After about 90 min of intense discussions within each of the groups following the 3 step process, both teams had their first version of the User Story Maps (see picture). Our team could only finish User Story definition for only 2 of the 3 personas that were in the case study.

At this stage, the teams were asked to vote and identify the Minimum Viable Product (MVP).

Finally, USM is not a one time exercise. The process is repeated, perhaps once a month, complimented by a more frequent Backlog Grooming.

The Meetup ended with a quick summary of the session and a final retrospective of what worked well and what could be improved in the next Meetup. As the retrospective showed, it was a great learning experience on a Saturday morning!