The 5 most common agile techniques

by Yvette Francino

Although people use a variety agile frameworks and methodologies in software development, it's common for organizations to take individual techniques from different frameworks and blend them in unique ways to create their own hybrid approach. The adaptable nature of agile actually encourages teams to use agile principles as a guide and to create the framework that’s most appropriate for their situation, rather than follow a prescribed set of processes.

Here are the five most commonly used agile techniques, according to VersionOne’s 10th Annual State of Agile Report. These techniques are used in Scrum, the most popular agile framework, so guidelines listed are those from the Scrum Guide. But it’s important to understand how these guidelines tie back to trusted lean and agile principles, so you can properly adapt them to your environment. Once you feel confident in the techniques, you can scale them for the enterprise appropriately.

1. The daily standup

The daily standup, also known as the daily scrum when used as part of the Scrum framework, is a short team meeting held at the same time every day. All team members are expected to physically gather and speak about what they worked on the day before, what they plan to work on that day, and any obstacles, or "impediments," they might be encountering. This meeting is the most popular agile technique.

You can use it no matter what framework you’re using, and it even works in traditional waterfall environments. Here are some of the guidelines recommended for this technique and how they relate to agile principles and values.

  • The purpose is to self-organize as a team, not to update management on what you’ve been working on

This is not a traditional status report meeting to management; it's recommended that managers aren’t even present. If they are, they should observe rather than participate or ask questions. In the daily standup, each team member is asked to focus on understanding the overall work of the team and how they can collaborate as a team to solve problems.

  • Meet every day at the same time with all other members of the team

One of the 12 principles of the Agile Manifesto states that development and business teams should meet daily. The daily standup provides that opportunity, ensuring that communication is taking place. The regular cadence prevents any confusion, and no time is wasted with scheduling changes—it simply becomes a regular part of each team member’s workday.

  • Keep the meeting to 15 minutes

The concept of "time-boxing," or being very rigid and disciplined about accomplishing an objective in a prescribed period of time, is commonly used in Scrum. Scrum time-boxes daily standup meetings to 15 minutes to keep the team focused. This meeting is not about problem-solving, but rather about gathering the most valuable, actionable information in the shortest amount of time. This idea of optimizing value and flow originates from lean principles. Problem-solving sessions can be scheduled outside the daily standup as appropriate with the needed people, but the daily standup is purposely kept brief so that the agenda is optimized, allowing the team to remain focused on their work, while still providing an opportunity for needed communication and collaboration.

2. Prioritized backlogs

Backlogs are used to keep track of the prioritized work that is to be done on a project. Unlike traditional waterfall projects, where requirements are stored in specification documents and must be planned in detail before development begins, in agile environments, requirements exist in prioritized lists of backlog items. As with the daily standup, you can use prioritized backlogs outside of Scrum. For example, you can use them if teams are using the kanban systemkanban system or are moving from waterfall to agile. Here are some guidelines for using prioritized backlogs:

  • Continually assess value of backlog items and re-prioritize accordingly

The use of a dynamic backlog is what allows us to use the agile principle "Welcome changing requirements, even late in development." Unlike the fixed-scope mentality of waterfall, where every change must be tracked and re-approved, change is expected in agile environments. It's one of the primary attributes that differentiates an agile framework from a traditional one. The use of a backlog in which work items can be adjusted for value allows teams to ensure that they can deliver the highest value to the customer quickly.

A screenshot of  a prioritized backlog in an agile management tool—Teams are aided by tools that can drag-and-drop to change rankings or sort stories based on various scores and prioritization calculations.

  • Progressively elaborate, letting details emerge

Backlog items are initially written from the perspective of customers, stating the value it provides to them. There are a variety of techniques you can use to evaluate value. However, unlike traditional environments, you don't discuss or decide upon the details of the implementation until the backlog items have reached the top of the backlog, indicating that they have a high priority. This prevents teams from spending a lot of time determining how to implement the details of features with a low priority and that may not ever be delivered to the customer.

3. Short iterations

Short iterations, which are often called "sprints," are another example of using a time box to accomplish specific goals. The short time period provides the opportunity to maintain focus on implementing a small set of the highest-value items in the backlog.

  • Keep the length of the iteration to a month or less

The Scrum Guide states that the length of the sprint should be a month or less. Most Scrum teams keep the iteration length anywhere between one and four weeks. By keeping the iteration short and giving it a regular cadence, the team can improve its understanding of how much work it can do during a given sprint.

  • Short iterations provide frequent feedback for learning and improving

Agile frameworks are considered empirical in nature. There are many unknowns. By executing in short iterations, the team is able to learn more and adjust in an incremental and iterative way. The shorter the iterations, the more often those adjustments and corrections can be made.

  • Keep the scope fixed during the iteration

During the iteration, the scope of the work that was agreed to during the iteration planning meeting remains fixed. Managers aren't allowed to disrupt the team's focus on the current iteration. But because the iteration is short, there isn't a long wait for managers to get high-priority changes into the next iteration.

  • Provide high-quality, valuable code at the end of the iteration

Perhaps the hardest part of keeping iterations short is the desire to create the highest-quality working code. The short iterations force the team to think about minimizing the size of user stories and coming back to refactor initial features piece by piece. This promotes the lean principle of optimizing value in the shortest amount of time. Although there is no rule that the code must be released to production at the end of the iteration, the code should be tested, and any known defects should be removed.

4. Retrospectives

Scrum introduced the retrospective—an event that occurs at the end of each iteration and provides the team with a formal process to "inspect and adapt," which simply means they continuously improve their workflow processes. The 12th Principle of agile states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

  • The meeting occurs after the work from the iteration has been completed and before the next iteration planning event

Although improvements can happen at any time, having a dedicated meeting about improving processes ensures that workflow optimization is happening. Without this prescribed event, the team would be tempted to skip retrospectives and become complacent, feeling that no improvements are needed. Even the most mature teams will benefit from reflecting on what went well, what could be better, and how they might continue to improve.

  • The retrospective should inspect how the iteration went and create a plan for adding improvements

It’s not enough to simply talk about what improvements could be made. The team must make active efforts to implement improvements. This can be done in a variety of ways, including adding items to the team’s backlog. The important thing is that the team agrees on how to make improvements.

  • The retrospective is a three-hour time-boxed event for a one-month iteration and is usually shorter for quicker iterations

As with the other events, Scrum prescribes a time box and has a Scrum master help the team adhere to their time box. If retrospectives are used outside of the Scrum framework without the Scrum master role, the team can agree on guidelines for the length of their meetings and how they will hold one another accountable.

5. Iteration planning

Iteration planning is the event in which the team agrees on the work that can be accomplished in the upcoming iteration. This is also the time when the team agrees how the work will be implemented.

  • Iteration planning determines how the work in the upcoming iteration will be delegated

Up until this event, the focus has been on what will be created, for whom, and for what benefit. Now, tough choices sometimes have to be made. Multiple items may reach high-priority positions on the backlog at the same time—more than your team can complete in one sprint—so the team must work together to determine what they can commit to finishing in the upcoming iteration. This is often done by decomposing user stories into specific tasks. Team members can then take ownership of those tasks.

  • The iteration is planned collaboratively by the entire team

The backlog items are originally written from the perspective of the customers who will benefit. The work is vague on purpose so that there’s no preconceived assumptions or directives from the business on the best ways to implement the code. The focus is on the value to the customer. Once the items have risen to the top of the backlog, the team must begin conversations with the business about the ways they might implement the requested work. This open conversation promotes transparency and collaboration of the cross-functional team, which collectively has expertise in development, quality assurance, and business needs.

  • The iteration is time-boxed to a maximum of eight hours for a one-month iteration

Once again, Scrum guidelines prescribe time-boxing the iteration planning event in order to provide focus and regularity. A maximum of eight hours is prescribed for a one-month iteration, with less time for shorter iterations.

Customize your own agile framework

Although these agile techniques all originated from the Scrum framework and have prescribed rules documented in the Scrum Guide, they are commonly used in hybrid or customized agile frameworks. By understanding the reasons behind these techniques and how they align with lean and agile principles, your organization can adapt and continually improve your own guidelines for these agile techniques even as you scale them to meet the demands of an enterprise-sized organization.

Further reading

The definitive source for using these techniques can be found, as mentioned above, in the Scrum Guide. However, understanding the principles is important in order to know how to adapt these techniques to your organization or to the larger enterprise.  Resources to better understand agile are abundant in the form of courses, papers, slide presentations, articles, and blog posts. In addition to the Scrum Guide, two good starting points include The Agile Alliance and the Scrum Alliance