The core idea of lean is to eliminate or at least reduce activities that don’t add value (waste) and thus increase the customer value. You can think of agile as a form of lean methodology for software.

My team follows an agile methodology that serves the needs at an enterprise level, producing frequent interim releases at every four sprints. At the end of an interim release the product is ready to be shipped. On adopting some of the best agile practices, our process became extra lean and increased efficiency by increasing the throughput.

There is no change in the agile framework that my team was following before and after. We simply adopted some of the generally accepted agile practices that made our existing agile software development approach leaner. Here are some of those practices.

1. Backlog Grooming

Backlog grooming is one of the agile practices my team adopted and practices religiously. My Scrum team meets regularly to keep the product backlog items clean and up to date. Like other agile events, the grooming meeting is a timeboxed event.

Grooming of Stories

The grooming meeting for stories generally happens once per sprint. The Scrum team does the following activities:

• Creates new stories for prioritized epics so they can be considered in the next sprints
• Adds or updates the acceptance criteria for each story from the backlog list
• Estimates the story based on the acceptance criteria. Yes, we do estimate some of the stories, but not more than we can complete in this interim release. The reason for estimating is to attain a state called definition of ready for the next sprint planning meeting.

The meeting is timeboxed to two hours for a sprint with two weeks. The team creates stories that would be worked for next sprints. We create the stories well in advance to solve any impediments we might encounter in addressing the stories. We have time to resolve those impediments from grooming to sprint planning meetings by talking to the product owner, architect, or any member who would help the team to clarify queries. As this activity happens in the background, there is no waiting time involved to remove any impediments identified in grooming meetings. By the time the team meets for the sprint planning meeting, members are clear about the sprint’s goal.

Along with creating the stories for the next sprint, we also update acceptance criteria for stories and estimate the stories. Considering the timeboxed event, we may not do this for all the stories for the next sprint. Any remaining stories would be updated with acceptance criteria and estimated during the sprint planning. 

Grooming of Epics

The grooming meeting of epics and features happens once per interim release. An interim release spans for four sprints. The product owner prioritizes the list of features he would like to see in the product based on the customer requirements and business priorities. The team spends time in grooming the epics and features as prioritized. The epic grooming meeting is also a timeboxed activity, with eight hours per interim release. These meetings are conducted on separate days and take half a day each. We go back to the product owner after the first part of the meeting for any clarifications.

The Scrum team performs the following activities during the epic grooming meeting:

• Identifies the activities to develop a feature and divides them so they are completed in one interim release by splitting the feature vertically
• Creates the stories for the identified activities of a feature or epic for the next interim release
• Adds the high-level acceptance criteria to the stories so they can be estimated
• Estimates the epic so we can commit how many epics we will be completing in an interim release

A backlog meeting is conducted to groom the stories or epics and attain a state called definition of ready. It helps us resolve any queries with product owners or stakeholders well in advance so the team will not face any impediments during planning meetings.

2. Acceptance-Criteria-Driven Development

Acceptance criteria for a user story are highly important and are required in agile software development as they indicate exactly what the product owner expects and what the Scrum team needs to accomplish. Test scenarios are captured as part of the acceptance criteria and signify the behavior of a feature after implementing. The story is said to be complete if acceptance criteria are met. Fulfilling the accepting criteria is one step in getting to the definition of done.

We are familiar with test-driven development, where a developer first writes automated test cases and codes a feature to get them executed successfully. These automated test cases get failed for the first time. As the developer starts completing his feature development, the test cases start getting passed.

Acceptance-criteria-driven development is an agile approach practiced by integrating test-driven development with acceptance criteria, where the feature development takes place against the acceptance criteria of a story. The developer understands and codes the feature to satisfy the scenarios of acceptance criteria. My Scrum team has been practicing this approach for some time now and the results are awesome! It has reduced the defect rates raised by Scrum teams. My Scrum team writes the acceptance criteria in such a way that it covers all possible scenarios with respective to the scope of the story and makes an effort in reducing the rate of defects. This increases the quality and brings more value to the product by making the agile process leaner.

My scrum team completes the following rituals when it updates the story to meet the acceptance criteria. 

Backlog Grooming

The product owner clearly defines and updates the acceptance criteria of epics and indicates his expectation. During the backlog grooming sessions, the Scrum team creates the stories for these epics to develop features. The team adds the acceptance criteria to the newly created stories under the guidance of an experienced team member who has the knowledge of product and domain. Later, my Scrum team discusses acceptance criteria for understanding and clarification.

Sprint Planning

During the sprint planning meeting, the team reviews the acceptance criteria for all the prioritized stories and updates them if required. The team commits to meet the sprint goal by agreeing to the objective of each story, which is captured as part of acceptance criteria.

Sprint Cycle

The developer picks up a story and starts coding the feature to fulfill the acceptance criteria. The story is claimed as complete only if all its test scenarios for acceptance criteria are met.

The set of activities typically followed in a sprint are shown in figure 1:

The acceptance criteria captured for stories should be detailed enough to be understood by any team member. This includes the different behaviors and scenarios related to a story. We include all different scenarios, leaving no room to file any defect related to a requirement or scenario. The only defect type that could occur is coding. This approach definitely reduces the number of defects that could occur during development.

We classify and include different test scenarios as acceptance criteria for a story. We add multiple sections, such as “Positive Scenario,” “Negative Scenario,” and “Nonfunctional Requirements/Performance Scenario” within the acceptance criteria.

After adopting acceptance-criteria-driven development completely, my sprint cycle looks as shown in figure 2:

 

3. Code Refactoring

Refactoring is the technical approach to restructuring the internal logic of the code without affecting its behavior and external identity. Refactoring is performed at many instances, such as to enhance code extensibility, to support new design, to address code smells, and so on. Not addressing the required code smells at the right time turns them into technical debt. Our team considers technical debt as some technical activity that is missed and postponed to later sprints and requires a completion. Therefore, code refactoring becomes important and needs to be performed regularly.

During the following events of development, my Scrum team started thinking of refactoring enough that they reached a state of “continuous refactoring”:

• Add or update a feature: The code is updated while adding a new feature. Think of refactoring every time the feature is added or updated. This brings the rigor of continuous refactoring.
• Fixing a defect: Follow three steps in fixing defects; red, green, and refactor. When the issue is present, it’s in the red state. Fix the defect first, which makes the status go to green. Then think of refactoring around the code that was updated as part of fixing the defect.
• Code review: When professionals review the code, they will have plenty of thoughts regarding the code design based on their experience in the domain and technology. Such reviews help 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 refactoring and it will become a habit leading to continuous refactoring.

4. Work in Progress Limit

Work in progress is a powerful kanban practice to limit the number of stories currently being worked on. The work in progress practice ensures the “stop starting, start finishing” philosophy in burning the stories. Mandating the work in progress limit ensures that in-progress stories are closed before new ones are started rather than multiple stories being worked on without being completed.

I have split the “In Progress” column on the Scrum board into two columns, “Under Development” and “Under Verification.” The Under Development column shows all the stories being coded by team members. Once the development is done, the stories need to be tested before they are claimed to be complete. Such stories are listed in the column Under Verification. The work in progress limit on these two columns ensures the stories are developed and tested within the same sprint to claim the story is complete before a new story is taken on. It reduces the waiting time of stories that otherwise would sit in the In Progress column.

Conclusion

Generally accepted agile practices are formulating our software development process using agile into an even leaner process. More features got delivered as the result of adopting these agile practices, as these practices helped to eliminate or reduce activities that don’t add value. After the delivery of the features, the team was ready to build the next generation of the software product. There is a never-ending journey.