Get certified - Transform your world of work today

Lean Agile Process

Making the Agile process still more lean

06/19/2014 by Prakash Mallappa Pujar

The core idea of lean is to eliminate/reduce non-value-added activities (termed "wastes") and thus increase customer value. The Agile process itself is a lean method for the software development life cycle, and I am sharing a couple of Agile best practices adopted by many teams to make the Agile process extra lean.

My team follows an Agile method that serves the needs at the enterprise level, producing frequent IRs (interim releases). (An IR consists of four sprints. Each sprint has two weeks in the sprint cycle.) At the end of an IR, the product is ready to ship if required. On adopting some of the best Agile practices, our process became more lean, to the point that it increased the process efficiency by increasing the productivity gain.

There was no change in the Agile framework that my team followed before and after. Few GAAPs (generally accepted Agile practices) are practiced religiously, which made our Agile software development approach a still more lean process. I summarize them here within the context of how these practices help make Agile even more lean.

1. Backlog grooming

Backlog grooming is one of the GAAPs in which the Scrum team meets regularly to keep the product backlog items clean and up to date. Like other Agile events, the grooming meeting can be a timeboxed event.

Grooming of stories

The grooming meeting of stories generally happens once per sprint. The Scrum team meets to carry out the following activities:
  • Creating new stories for prioritized epics so they can be completed in the current interim release
  • Moving the prioritized stories to the top of the backlog
  • Adding/updating the acceptance criteria for each story from the backlog list
  • Estimating the story based on the accepting criteria
The meeting is timeboxed to two hours for a sprint of two weeks.

Grooming epics

The grooming meeting of epics/features happens once per interim release (which consists of four sprints). The PO will prioritize the list of the features that he would like to see for the product based on customer requirements and business priorities. The team spends time in grooming the epics/features as prioritized by the PO. The epic grooming meeting can be a timeboxed activity of eight hours per IR.

Following are the activities performed by the Scrum team during the epic grooming meeting:
  • Identifying the activities to develop a feature and divide them so that they are completed in one IR by splitting the feature vertically
  • Creating the stories for the identified activities of a feature/epic for the next IR
  • Adding the high-level acceptance criteria to the stories so that they can be estimated
  • Estimating the epic

2. Acceptance Criteria-Driven Development

Acceptance Criteria-Driven Development (ACDD) is an Agile approach practiced by integrating TDD with acceptance criteria. It reduces the defect rates as all the test scenarios would have been covered as part of acceptance criteria, and thus it increases the quality and value of the product by making the Agile process more lean. This approach of practicing Agile is influenced by Test-Driven Development.

3. Code refactoring

Refactoring is the technical approach in restructuring the internal logic of the code without affecting its behavior and external identity. Usually refactoring is performed to improve the NFRs (nonfunctional requirements) or to provide the extendability to the code. Refactoring is a technical debt and becomes a non-value-added activity if it is not addressed at the right time as per lean principles. Hence code refactoring becomes important and needs to be performed regularly. During the following development events, think of reaching a state of "continuous refactoring":
  • Add/update a feature: The code is updated while adding a new feature. After completing the implementation of a feature, think of refactoring. Think of refactoring every time a feature is added or updated. This brings the rigor of continuous refactoring.
  • Fixing a defect: Follow three steps in fixing the defects: red, green, and refactor. When the issue is present, it's in a red state. Fix the defect first, which makes the status green, as the feature has no defect. Then think of refactoring around the code that was updated as part of fixing the defect.
  • Code review: When experienced professionals review the code, they will have plenty of opinions about its design based on their experience in the domain and technology. Such reviews help experienced senior developers pass their knowledge to junior developers. While the developers incorporate the code review comments, think of refactoring. Based on the guidelines of experienced developers' suggestions, the developer does the refactoring. Keep doing the refactoring; it becomes a habit that leads to continuous refactoring.


The main purpose of this article is to share how GAAPs could help move Agile into a more lean process.

Backlog grooming

On conducting regular backlog grooming sessions, the team is well prepared for the sprint planning meetings attaining "Definition of Ready" for sprint/IR planning meetings. Having groomed the stories in the previous sprints, it helps to address the required dependencies and design discussions/decisions before planning meetings, thus reducing any waiting time.

Acceptance Criteria-Driven Development

Having the acceptance criteria for every story, it ensures that the developer implements the feature to satisfy the requirements of the PO. The acceptance criteria has multiple sections with all possible scenarios, which reduces the probability of defects, which contributes in making the process still more lean. Addressing defects is a non-value-added activity.

Code refactoring

If refactoring is not addressed at the right time, then it becomes a technical debt. Today's technical debt will become tomorrow's waste, as it requires effort to address it. Technical debts need to be addressed immediately before the product is shipped as part of next incremental release. Such refactoring efforts will trigger a reach for a state called continuous refactoring.