Agile is a mindset that’s based on the 4 values and 12 principles in the Manifesto for Agile Software Development, which give birth to an unlimited number of agile practices.
These practices are often packaged in agile frameworks that act as training wheels for the adoption and application of agile by teams and individuals. But they are as effective and perfectly good on their own.
What are agile practices?
Agile practices, like keeping teams small, collaborating with the customer, and keeping a product backlog, are specific ways in which organizations, teams, and individuals can adopt and use the agile mindset.
I spent days filtering through some of the best agile practices out there and collected them in this longform, and hopefully useful, post.
Like all things agile, I’m going to keep evolving this list by adding new practices to it every so often. Those of you who found it useful are more than welcome to put it in their browser bookmarks—and revisit it every now and then to look for changes.
Team Practices
Small Team
Agile is based on the idea that small teams perform best.
How small? It depends on your organization, team, situation—as well as the agile framework that you’ve chosen to use.
Most Extreme Programming (XP) teams vary from 5 to 12 people. The roles on the team are Customer, Programmer, Tester, Manager (also called “Tracker”), and Coach.
Scrum teams vary from 3 to 10 people (it used to be 9, but the 2020 update to the Scrum Guide changed that). The roles on the team are Product Owner, Scrum Master, and Developers.
In 1970, social psychologists Richard Hackman and Neil Vidmar found that the optimal size for a team is 4.6 members.
Hackman and Vidmar asked students at Yale University and the University of Illinois, Urbana, to complete 36 tasks—each 15 minutes long—in groups of various sizes.
Then, they asked each participant how strongly they agreed with a list of 20 statements, which were designed to elicit the optimal team size. The statements included:
- The group was too small for best results on the task it was trying to do;
- The group was too big for best results on the task it was trying to do.
The two social psychologists shared their findings in an article titled “Effects of Size and Task Type on Group Performance and Member Reactions” in the March 1970 edition of the journal of Sociometry.
Cross-Functional Team
High-performing agile teams are self-organized. Self-organization requires the team to be cross-functional (or, in a way, self-sufficient).
In the agile community, people often misinterpret agile and some agile frameworks (especially Scrum) by thinking that they’re only intended for programmers and for the software development field as a whole. That’s only partially true.
Yes, agile began as a movement among software developers when a group of 17 thought leaders in the field came up with the Manifesto for Agile Software Development on a ski retreat in Snowbird, Utah. But it’s been two decades since—and agile has grown, as a mindset and as an approach to leadership and getting things done, beyond the Development Team and IT department.
Which leads me back to the original topic of cross-functionality.
An agile team should be cross-functional in the way that its members have all the necessary know-how and skills to achieve the goals that they want to achieve.
The typical Development Team doesn’t consist of just Programmers. It also has Software Architects, Testers, Database Administrators, DevOps Engineers, Site Reliability Engineers, UX Designers, Business Analysts.
The agile practice of cross-functionality comes from a research paper by Hirotaka Takeuchi and Ikujiro Nonaka called “The New New Product Development Game” in the 1986 edition of Harvard Business Review.
Jeff Sutherland and Ken Schwaber, two of the co-signers of the Agile Manifesto and the creators of Scrum, often point to the study as one of their primary sources of research back when they were creating the Scrum framework.
Takeuchi and Nonaka studied some of the leading American and Japanese product companies in the 1980s (including 3M, Brother, Canon, Hewlett-Packard, and Honda) and discovered that they had a “new new” approach to product development.
Instead of using the traditional linear and sequential method for product development, which very much resembled waterfall software development, these companies built small and multi-disciplinary teams, gave them hard challenges, and allowed them to self-organize and work in overlapping phases.
“Under this new approach, the product development process emerges from the constant interaction of a hand-picked, multi-disciplinary team whose members work together from start to finish,” the article by the Japanese organizational theorists said.
Colocated Team
The sixth principle in the Agile Manifesto is that “the most efficient and effective method of
conveying information to and within a development team is face-to-face conversation.” This gives birth to the agile practice of a colocated team.
This is reflected in one of the values of Industrial XP, a lesser-known fork of the Extreme Programming (XP) framework. The value is called “Sitting Together” and it says that, to set up a team for success, the team should sit together. “This enables the team members to collaborate effectively and efficiently.”
In most organizations today, where product development is done in distributed teams, colocation is not always possible.
And much has changed in the way that people design, code, build, test, deploy, release, operate, and maintain software since Manifesto for Agile Software development was written in 2001 and Industrial XP was conceptualized in 2004.
Yet one thing remains true: communication and collaboration happen best when a team’s members are sitting next to each other. Apply this practice, even if your team is distributed. Every now and then, a situation warrants a change of plans so big, it warrants an in-person workshop. The challenge then becomes to not overdo it (as most companies tend to do).
Colocation is not a silver bullet. In their 1987 book Peopleware: Productive Projects and Teams, Timothy Lister and Tom DeMarco talk about the importance of creating a non-distracting workplace for development teams. They advise against the open office and recommend that individuals and teams should be given private spaces where they can achieve a state of flow (which is basically a state of high productivity achieved through deep focus).
So keep that in mind when you’re considering how to best apply the agile practice of colocation. It’s not just about being physically together. It’s about protecting yourselves from the unidentified flying distractions of the modern workplace (yes, that includes chat messages and systems alerts).
Accountabilities
The 2020 update to the Scrum Guide introduced the agile practice of accountability.
The Scrum Team is accountable for creating a valuable and useful product increment every sprint. To achieve that, the authors of the Scrum framework renamed roles to accountabilities.
Since, a Scrum Team consists of team members who can have one of the three accountabilities:
- Product Owner
- Scrum Master
- Developer
The Product Owner is accountable for maximizing the value of the work that the Scrum Team is focusing on. They do so through formulating the product and sprint goals, as well as ordering the product and sprint backlogs.
The Scrum Master is accountable for establishing Scrum as described in the Scrum Guide. They do so through ensuring that the Scrum events are in place and by teaching, mentoring, coaching, and facilitating the Scrum Team and its stakeholders on how to best use them.
The Developers are the people in a Scrum Team who develop the product (no matter if they write code or not). They are accountable to create a plan for the sprint by committing to do items on the sprint backlog and adapting their plan as they ship increments to achieve the sprint goal.
The person in the Product Owner, Scrum Master, or Developer role is ultimately accountable for the accountabilities of that role. They can choose to delegate some of their responsibilities for that role to their team members as the situation allows, but they stay ultimately accountable.
Customer Practices
Colocated Customer
Some agile frameworks say that the customer should be on-site and available on-demand. Extreme Programming (XP), for example, says that “the customer should always be available.” All phases of an XP project require communication and collaboration with the customer, preferably face-to-face and on-site.
In Scrum, the customer is the Product Owner, who is essentially a full-time part of the team. Big companies often implement Scrum by assigning someone from the Business to play the role of the Product Owner—and staffing their Developer accountabilities with in-house employees or vendor resources. The reality is that the Product Owner is often more of a proxy customer, but they are expected to represent the customer in their true and complete interests.
The Scrum Product owner does this by being accountable for the product goal and sprint goals, as well as for the formulation of the work items and their sequencing/ordering on the product backlog and sprint backlogs. Through their participation and decisions, the Product Owner maximizes the value of the work that the Scrum Team is doing.
Similar to the Product Owner, the Customer in XP is expected to write user stories and assign them with a priority that reflects their definition of value. They participate in the release planning by helping determine the timing and scope of releases. When necessary, they talk about a user story with a Programmer to make sure that they have the best understanding for what needs to be done. Finally, they help with functional testing—and have the final say whether or not a release should go to production based on the testing outcomes.
No matter where your organization is on its agile journey and which agile framework your team is using, customer availability and participation is key. This is where many agile projects fail as:
- The person representing the customer is not representing them well;
- The person representing the customer is generally not available and participating;
- The person representing the customer is not there at all (collaboration is therefore missing).
The customer should always be available. This is not only in their best interest in an agile project; it is a necessity for the project to succeed in the first place.
Customer Collaboration
Agile delivery happens through collaboration between the individuals and teams doing the work and the customer defining the work. This is the reason why projects that take an agile approach require significantly more involvement from the customer at all stages when compared to projects that take a waterfall approach.
In my experience, I’ve come to the conclusion that there are five traits of collaborative customers whose involvement tends to lead to greater outcomes on agile projects.
At their best, the collaborative customer should generally be:
- Available to the team;
- Willing to communicate openly;
- Willing and to collaborate and participate;
- Able to make decisions and trade-offs about the work;
- Capable of making good decisions to balance innovation and maintenance.
For the collaboration to work, the agile team should be respectful of the customer, trusting their judgement and valuing their decisions.
Respect also means readiness to have dialogue about the consequences and trade-offs that may seem obvious to the team, but for one reason or another are not obvious to the customer.
Stakeholder Participation
The stakeholders of an agile initiative, program, project, product, or service are invited (and encouraged) to participate in the events intended for them.
Usually, these events are Iteration Demos or Sprint Reviews, which are intended to elicit their feedback and capture their inputs, which help the agile team to make a better-informed plan for the iterations or sprints to come.
Getting stakeholder participation right is difficult to do. The more senior the stakeholders, the less time they have to dedicate to individual projects and teams. The challenge is in taking enough of their time to obtain the right level of inputs or decisions from them.
Some companies solve this problem by adopting “scaled” agile frameworks like Scrum@Scale, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), or Disciplined Agile Delivery (DAD). These frameworks give roles, events, and artifacts to (most of) the people in an organization beyond the single development team.
Other companies solve it by taking the mindset, values, and principles of agile—and creating events and practices of their own. An example of that is Basecamp, the company behind one of the world’s leading project management and team collaboration apps.
Basecamp is a company that works in 6-week cycles that they call “bets.” In-between these cycles, the Basecamp team has a meeting called the “betting table” where the CEO, CTO, a Senior Programmer, and a Senior Product Strategist get together to determine what to bet on next (what to do for the next 6-week cycle).
The meeting is kept short and concise. The people on the betting table consider only a small number of options. The outcome is a plan for what to focus (bet) on for the next 6 weeks. No other commitments or promises are made during that time. Any work that could be done becomes a pitch to consider for the next betting table.
This way of working is described in specifics by Ryan Singer, Head of Product Strategy at Basecamp, in his 2020 book Shape Up: Stop Running in Circles and Ship Work that Matters.
Empirical Practices
Agile theory (as well as the theory behind most agile frameworks) is based on empiricism.
Empiricism is a philosophical school of thought that gave rise to experimental science in the 17th century. Empiric thinkers believe that the best way to attain knowledge is through “sensory experience.”
Translated to agile terms, you can only tell if a plan is going to work out or not by trying to make it happen. Your best approach, then, is to keep your hypotheses nimble and your plans short—seeking out feedback as to whether they’ll work out or not early and often.
Below, I’ve collected some of the most common agile practices for applying empiric thinking.
Feedback Loops
Agile teams work in short cycles and ship in small chunks. In doing so, they create a cadence; a unique rhythm of sorts that allows them to create feedback loops for their work.
To understand how feedback loops work, consider a thermostat in a room:
- When the temperature reaches 70°F, the thermostat turns off (or dials down) the heating system. This is an example of a negative feedback loop.
- When the temperature drops below 68°F, the thermostat turns on (or dials up) the heating system, bringing back the temperature to its desired level. This is an example of a positive feedback loop.
The first principle of agile is to satisfy the customer through early and continuous delivery of valuable software. How do high-performing agile teams apply that principle in practice?
Agile teams take an empirical approach to applying that principle by working in short cycles and shipping in small chunks, effectively accelerating the feedback loop.
Accelerating the feedback loop has a number of benefits for the team building the product and the organization sponsoring it. Perhaps the biggest benefits are improved predictability and greater control over risk. Plans are plans—and some of them will inevitably go wrong. But making short plans and adjusting plans often is how agilists keep mistakes to a minimum.
When your plans are systematically coming out ineffective (delivering the wrong thing), consider shortening the business/customer feedback loop.
When delivery is systematically coming out inefficient (delivering the right thing in a wrong and difficult way), consider shortening the procedural and technical feedback loops.
Objectives & Key Results (OKRs)
Objectives & Key Results (OKRs) are one way that leaders, managers, and owners can apply feedback loops to complex projects in ambiguous environments.
OKRs were created by Andy Grove, who introduced them at Intel as a management framework in his tenure as CEO. He documented his principles for how OKRs work in his 1983 book, High Output Management.
An OKR is a simple statement that consists of an Objective and a set of 3-5 Key Results. The best OKRs are simple, self-explanatory, and written in plain language. For an OKR to work, the Objective should be a clearly-defined goal.
The Key Results should be measurable results that the team working to achieve the objective can use to tell whether or not they’re getting there. Key Results can use any measure that’s relevant to the organization (for example, 1 – 100, %, U.S. dollars, or other).
In Andy Grove’s explanation in the book, an OKR is the highest-level management tool that a leadership team can use. OKRs then cascade down into the initiatives, programs, and projects that the organization is sponsoring.
The best OKRs, he adds, are the ones that a team can only achieve up to 70%. This encourages everyone in the organization to think bold and set ambitious goals.
If 70% or more of the Objectives and Key Results are consistently being met, the organization should learn how to set more ambitious goals for itself.
Plan, Do, Check, Act (PDCA)
Plan, Do, Check, Act (PDCA) is an agile practice that individuals, teams, and organizations can use to implement feedback loops in a repeatable way.
The PDCA loop is also known as the Deming cycle (named after W. Edwards Deming and his work on business process management in the 1950s) and the Shewhart cycle (after Walter A. Shewhart and his 1920s work on implementing feedback loops in the Hawthorne factory).
In its simplest form, here’s how a PDCA loop works:
- Plan a change aimed at bringing an enhancement or improvement to the status quo;
- Do the implementation of that change as originally planned and as intended;
- Check the results of that change to determine what actually happened;
- Act as you see fit based on your observations for what happened.
Like many things agile, feedback loops are simple to understand and hard to master. To make the PDCA loop work for your organization and team:
- Make nimble plans grounded in reality;
- Do the minimum work required to achieve the maximum outcome;
- Weigh the results as objectively as possible, no matter if you’re doing so in qualitative or quantitative terms;
- Be decisive and quick in your actions.
Inspect & Adapt
One of the simplest forms of feedback loops in agile is Inspect & Adapt.
Inspect & Adapt comes from the Scrum framework and is described in detail in the official Scrum Guide.
Like all agile frameworks, Scrum uses an iterative and incremental approach. This approach helps the teams that practice Scrum (and the organizations that sponsor them) to optimize predictability and control risk.
“The Scrum artifacts and the progress toward agreed goals,” the Scrum Guide says, “must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.”
These events include:
- The Sprint, which acts as a timebox for the iteration and a container for all other events;
- The Sprint Planning, in which the team plans how to meet a goal for the iteration (the Sprint Goal);
- The Daily Scrum, in which the Developers in the team sync up and adjust their plan as they move closer to the end of the iteration;
- The Sprint Retrospective, in which the Scrum Team discusses what went well, what didn’t, and what they can do differently in the next sprint;
- The Sprint Review, in which the Scrum Team demonstrates the work that they’ve completed (the Increment) to their stakeholders, collects their feedback, and captures their inputs to be able to make a better-informed plan for the next sprint.
When it comes to adaptation, the Scrum Guide says: “If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.”
Problem, Options, Experiment, Review (PrOpER)
Problem, Options, Experiment, Review (PrOpER) is another form of feedback loop that agile teams can use to their advantage.
PrOpER is mostly used by Agile Coaches as a tool for helping teams to boost their situational awareness, so that they can become better at making informed choices and tracking the results. It’s also a great tool that any agile team can do on their own—no matter if they have access to an Agile Coach or not.
Here’s how PrOpER works:
- Pick a problem to solve. At this stage, the goal is to come to the most truthful and accurate description of what the problem is. This step can sometimes be very hard to do and ends up surprising agile teams with its difficulty;
- Consider your list of options. As humans, we have a natural tendency to jump to conclusions and solutions. This step forces you and your team to stop and think about all of your options. Sometimes, you have more choice than you initially think;
- Select an option and experiment with it. After having evaluated the situation and listed your options, now is the time to choose and implement one of the options;
- Review the outcome. Did you formulate the problem right? Did you consider all the options? Did the option you chose produce the change or results that you and the team intended? What lessons did you learn that can help you do all of the steps above better the next time you solve this problem (or use this feedback loop for other problems)?
There you go. You now have a list of four forms of feedback loops that you can use in any situation: OKR, PDCA, I&A, and PrOpER.
Which one is your favorite? Have I missed any of your favorites on our list? Let me know in the comments section below.
Planning Practices
Timeboxing
The hours on the clock and the dates on the calendar are timeboxes. They allow you to manage time—and give you the freedom to use them as you wish, for any activity you see fit.
Like the hours on the clock and the dates on the calendar, timeboxing allows individuals, teams, and organizations that practice agile to stay focused and create cadence.
Product development is a game of trade-offs. An agile team that’s building a product needs to take an economic view. In any given unit of time, they can only do X or Y. Of course, they can also choose to do X and Y and complete neither—that is a real and valid choice.
Timeboxing allows the team to stay focused on what to do and what not to do in their daily interactions and in their day-to-day-work. By keeping meetings timeboxed, the team reminds itself to keep to the point. By keeping iterations timeboxed, the team focuses on what they can commit to.
Over time, timeboxes create cadence. Merriam-Webster defines cadence as a regular and repeated pattern of activity. When an agile team and its stakeholders understand the concept of cadence, they focus on making good decisions for the short term that lead to better ways of working and outcomes in the long term. Agile development is a long-term game.
Short Iterations
Agile is based on the principles of empiricism and lean. In empiricism, the only way to check if a plan is going to work out or not is to try to make it happen. In lean, the best way to make plans happen is by focusing only on what delivers value—and doing your best to eliminate waste.
This is why one of the key practices of agile is to work in short cycles (iterations).
Agile teams that work in short iterations can work effectively and deliver efficiently. Effectively, because working in short iterations allows them to adjust their plans to always work on the right thing. Efficiently, because keeping iterations short allows them to deliver a working product in small chunks.
The Agile Manifesto says to “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Indeed, most XP teams work in iterations that are 1-3 weeks long and most Scrum teams work in 1-4 weeks long sprints.
Iteration Planning Meetings
Agile teams work in an iterative and incremental way.
Iterative because an agile team makes plans and gets things done in short cycles, usually 1-4 weeks long, called “iterations.” Incremental because in each iteration, the team ships the product in small chunks called “product increments” or simply “increments.”
At the start of an iteration, an agile team usually has a meeting (or working session) to plan what goal they’re going to try and meet—and what work items (epics/features, user stories, tasks, sub-tasks) they’re going to deliver in order to meet it.
Each agile framework gives these planning meetings a different name. In Scrum, iteration planning is done during the Sprint Planning event. In Extreme Programming (XP), it’s done during the Iteration Planning event.
Other agile frameworks, like the Scaled Agile Framework (SAFe), prescribe Program Increment (PI) Plannings involving a big group of all the employees and vendors required to get systems in a corporate context built.
No matter how your organization and team practices agile and which agile framework it has chosen to use, here’s my best advice for how to conduct an effective iteration planning:
- Write, refine, and estimate work items on your product backlog before the iteration planning meeting;
- Start with a clear and understandable goal for the iteration that helps the team to focus on the work of highest value;
- Remember that estimates are relative and inaccurate, but don’t forget to plan realistically based on your velocity and capacity;
- Iteration planning is as much about what to do as it is about what not to do. Determining what is non-negotiable and making trade-offs is key;
- Once you’ve planned your iteration, set out to deliver the plan. Agile allows your team to stay flexible in how you deliver—as long as you stay focused on the iteration’s goal.
Like most events in agile, the iteration planning is awkward and difficult in the start, but starts to feel normal and become productive over time.
Iteration Review Meetings
At the end of an iteration, an agile team demonstrates the completed work to their customer, seeking out feedback and using it to adjust their plans for the next iterations to come.
The demonstration is usually in the format of a show-and-tell, and the customer is usually represented by one or multiple stakeholders who attend and participate in the iteration review meeting.
“Completed work” can mean different things for different teams. In its most general sense, it means completed work items during the iteration that meet the team’s Definition of Done (DoD). The DoD should therefore reflect the repetitive requirements of the customer, organization, industry, or any standards or regulations that the team needs to follow. When such a requirement emerges that wasn’t foreseen, the team adds it to their DoD.
In Scrum, the iteration review event is called Sprint Review. The Scrum Team demonstrates the work that was done during the sprint to the stakeholders that are invited—seeking out their feedback and using it to adjust their plans for the next sprint/s.
Many Scrum Teams misinterpret the purpose and value of the Sprint Review event. The event is not intended to be “just a demo” where the Developers do a status report on what was done and the stakeholders stay silent. It should be a conversation and collaboration between the team and its leaders, sponsors, customers, users, and/or any other interested stakeholders.
In other words, high-performing Scrum Teams use the Sprint Reviews to engage their stakeholders and elicit the feedback and insight they need to plan at their best. On the other side, these teams have high-performing stakeholders who are interested in the progress of the product and participate in the events of their Scrum Teams. Agile is a two-way game between the team building the product and the organization that sponsors it.
Standup Meetings
A standup meeting (or just “standup”) is a short meeting that its participants attend standing. Standing prevents the participants from getting distracted by calls, emails, chats, notifications, work, and other distractions in their workspace.
The standup meeting should be brief and to the point. The discomfort of standing in one place for prolonged periods is intended to be a reminder to the participants for keeping them that way. For example, the Scrum framework timeboxes its version of the standup, called the Daily Scrum, to 15 minutes.
The purpose of the standup meeting is to help an agile team’s members sync up on status, inspect their progress toward the sprint goal, and adjust their plans if and where necessary—so that they can maximize their chances of meeting it.
To shorten the feedback loop, most agile teams hold their standups daily. Usually, each member of the team answers the following questions:
- What I did yesterday
- What I’m planning to do today
- Whether or not I have any impediments I can’t resolve on my own
As each member of the team shares their progress toward the iteration goal and syncs their plans up with their teammates, the team continually course-corrects based on the real outcomes of their work and the lessons learned from their implementation. This allows the team to be highly responsive to unforeseen challenges and adaptive to change on a daily basis.
An effective daily standup meeting is not just a status report. It’s a conversation and a collaboration in which the team comes up with a mini-plan for the working day and storms together on removing impediments that one member, multiple members, or the entire team is facing.
Retrospective Meetings
An agile team continuously improves their ways of working. To achieve continuous improvement, most agile teams use the practice of conducting retrospective meetings.
The term “retrospective” was popularized by Norman Kerth in his 2001 book, Project Retrospectives: A Handbook for Team Reviews. This type of meeting is also known as an “iteration retrospective” in some agile frameworks and “sprint retrospective” in the Scrum framework.
A retrospective meeting takes place at the end of an iteration. The agile team uses it to discuss:
- What went well in this iteration
- What could have gone differently in this iteration
- What action items the team’s members are going to take to do things differently in the next iteration
Retrospectives are most effective when they focus mostly on what happened in the iteration that’s ending and what the team’s members plan to do differently in the next iteration. Keeping the time horizon short allows the team to focus on concrete problems and doable solutions.
As a team makes small changes to their ways of working with the lessons learned from each iteration, over time these changes tend to add up—leading to marginal gains in effectiveness and efficiency in the three areas of People, Process, and Technology for that team.
High-performing agile teams use the retrospective meetings to make small improvements iteration by iteration, not forgetting that these small improvements in the short term lead to big improvements in the long term when the gains they introduce are summed up.
Release Planning Meetings
Release planning is a meeting in which an agile team makes a release plan. A release plan is a plan for what features of or enhancements to a product to release in which version of that product.
Release planning is necessary on projects where one or multiple agile teams are building a software product for which product versioning and feature/enhancement predictability are key requirements.
Typically, a release plan spans across multiple iterations (in most cases, 2-4 iterations). To make delivery predictable, the release plan determines the goals and commitments that the agile team is going to make in these iterations.
Depending on the agile team, the product they’re building, and the needs of the customers and/or organization sponsoring it, a release plan can be very high level (for example, multiple bullets with names of features listed under an upcoming version of the product) or very specific (for example, a list of features or changes linked to the individual work items on the backlog of the team).
A release plan is simply a plan for what to release in the coming iteration/s. It shouldn’t be confused with the requirements that the team captures on the backlog or the plan for a single iteration. Since agile welcomes change at any stage of the plan, iteration plans are not strict and non-negotiable commitments and are subject to change if and when that is necessary.
An agile team plans their releases by time or by scope, but seldom by time and scope together.
When planning an iteration by time, the team commits to releasing version X of a product on a given date. The scope of the release remains flexible and is determined in collaboration with the customer, so that the work items of the highest value get released first (and the outcome of the team’s work is therefore maximized).
When planning an iteration by scope, the team commits to releasing version Y of a product with a given set of features. The timing of the release remains flexible and is determined by the time required to deliver the features required for the release. The team and its customer can make changes to the scope at any time to adjust their plans based on lessons learned.
Planning a release by time and scope may seem like a good idea. On the surface, it seems to add more certainty and predictability as both the time and the scope of a release are known. The reality is that it’s often misleading, as time and scope are two variables that add more complexity and certainty to the equation, thereby making the plan unreliable.
To make a release plan, the team uses velocity and capacity.
Velocity is the measure of work completed in the previous iteration (or the average amount of work completed in multiple previous iterations).
Capacity is the actual ability of the team to do work based on their availability. When planning, it is a good practice to account for vacations, bank holidays, and distractors.
For example, if the team completes on average 20 story points worth of work in a single iteration and has 50% capacity in the upcoming iteration, the release plan should factor that in and forecast only 10 story points worth of work during that iteration.
Refinement Practices
Product Backlog
The product backlog is where an agile team captures all of the requirements and work that needs to be done to build their product.
The product backlog is a live artifact. The team creates it and keeps it always up to date, often in close collaboration with their customer.
The items on the product backlog are ordered in any way that allows the team to sequence and/or prioritize their work to deliver the items of highest value first.
There’s no one-size-fits-all approach to the delivery of value and a team can formulate and order the work items on their backlog as they best see fit for their delivery needs.
Most agile teams tend to formulate their work items as epics, user stories, tasks, and/or sub-tasks (I will cover these practices later on in this post).
Also, one of the most useful principles for ordering a backlog that I’ve come across is WSJF, or Weighted Shortest Job First. The WSJF method is based on a simple equation:
WSJF = (Cost of Delay / Job Size)
The cost of delay and the job size are relative measures. Since job size is usually estimated as story points to deliver individual user stories—and story points are based on the Fibonacci sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …, n)—it is useful to measure both the cost of delay and the job size using Fibonacci numbers.
When measuring the cost of delay in Fibonacci numbers, I call the resulting measure “opportunity points.” The name comes from the concept of opportunity cost in economics, which represents that to choose to pursue one opportunity, you need to forgo the pursuit of another.
Here’s an example of WSJF use for a set of three features:
| Feature | Cost of Delay | Job Size | WSJF | Sequence |
|---|---|---|---|---|
| Contact form | 21 opportunity points | 3 story points | 7 | First |
| Registration form | 13 opportunity points | 8 story points | 1.625 | Second |
| Adjust font size | 3 opportunity points | 13 story points | 0.23 | Third |
Iteration Backlog
The iteration backlog is a subset of the product backlog. The iteration backlog is an ordered list of work items that an agile team plans to work on during an iteration. Usually, the iteration backlog is the output of the iteration planning meeting.
Teams have different approaches to iteration planning depending on the level of certainty (or uncertainty) they work in. Some teams only make plans one iteration at a time, whereas others make plans for multiple iterations ahead of time (usually 2-4 iterations at a time).
When a team makes a plan for multiple iterations at a time, they usually do it as part of the release planning practice (described one item in this list above).
Task Board
The task board is a visual display of the status and progress of the work items an agile team delivers during an iteration.
The task board contains columns. Each column represents a status and acts as a container for work items that are currently in this status. The simplest set of statuses that agile teams usually start with is “To Do”, “Doing”, and “Done.”
As a team matures, they tend to change their task boards to more specific columns/statuses that represent their true workflow. For example, a team could change the simple “To Do,” “Doing,” “Done” task board to “Planned,” “Assigned,” “Development,” “Testing,” “Deployed,” and “Released”.
There are two goals behind a task board:
- Visualize work in progress
- Make visible opportunities for continuous improvement
By visualizing work in progress, the task board helps the agile team manage the work items that they’ve committed to deliver.
By making the workflow visible, the team can continuously improve it by identifying steps that they can improve or automate.
The task board can be as simple as a whiteboard with sticky notes that represent individual work items. However, most teams (especially distributed teams) prefer to keep their task board digital and in a collaboration app like Trello, Jira, Azure Boards, or other.
Value Streams
A value stream is the series of steps that an organization takes to deliver value for a customer from the first to the last interaction with them when it comes to a specific use case for a product or service.
The concept of value streams and the practice of value stream mapping (described below) originate from lean management. Their purpose is to help organizations visualize the as-is state of how they deliver value to customers and plan a to-be state that improves the flow of value.
In agile, value streams are a practice primarily in the Scaled Agile Framework (SAFe). Value streams help organizations to determine the IT systems and development projects that they need to sponsor, so as to enable a certain flow of value for customers through a product or service.
For example, a taxi startup identifies the following value stream for its customers:
They then determine what IT systems will be needed to enable the delivery of this value stream:
To provide their taxi service to customers, the startup needs:
- An app for riders (customers)
- An app for drivers (employees)
- A Customer Relationship Management (CRM) system to store customer data in
- A Global Positioning System (GPS) to manage routes to and for rides in
- A Payment Gateway system to process bank card payments
- An Invoice System to issue invoices to customers
The startup can then allocate budgets to sponsoring the agile teams to purchase, build, and/or integrate these systems.
Value Stream Mapping
Value stream mapping is the exercise of mapping out value streams.
A value stream is the series of steps that an organization takes to deliver value to its customers for a specific use case. Each value stream has a start and an end.
The start of a value stream is normally the first interaction with the customer, in which they express interest in or directly purchase a product or service. The end of a value stream is usually the last interaction with the customer, in which they dispose of the product or terminate their use of the service.
In general, there are two types of value stream mapping:
- The value stream mapping prescribed by lean management and also known as “material- and information-flow mapping”;
- The value stream mapping prescribed by the Scaled Agile Framework (SAFe).
Though they’re based on a similar approach, they look at an organization and its value streams in different levels of specificity and from different points of views.
Material- and information-flow mapping is typically used by companies with complex value chains whose core business involves the manufacturing, logistics, and/or sale of physical goods to businesses or consumers. It helps management teams to map the flow of value, from a materials and information point of view, and measure the time it takes to complete each step (as well as the value stream holistically).
Value stream mapping in SAFe is based on the same concept, but looks at the value stream from the perspective of the customer journey and the IT systems that need to be built, integrated, and operated/maintained so as to enable them.
Themes
A theme is a group of epics.
Epics
An epic is a group of user stories.
There is no “true” way to write an epic. Some teams keep epics as simple as possible, assigning them with a name, priority, and estimate (calculated as the total amount of story points of all the user stories linked to them).
Others define epics in a more detailed way, oftentimes using templates like the Epic Hypothesis Statement template proposed by the Scaled Agile Framework (SAFe):
User Stories
A user story is a simple and informal description of a functionality on a product. User stories are self-contained and self-descriptive. They capture all the information necessary and convey it in plain language, so that anyone who is reading them can understand what they are about from first glimpse.
A user story can be written in any format that makes sense for the agile team.
Many agile teams choose to standardise the creation of user stories using the following user story template:
As a (user), I want to (job to be done), so that I can (goal).
For example:
As a Product Owner, I want to understand how to create better user stories, so that I can convey the value of the work to the Developers in my team more clearly.
Some Product Owners and Business Analysts like to give their user stories names. In the case of our example, a good name would be “Understand the user story template.”
After user stories are captured on the backlog, they are usually given a priority by the Product Owner and estimated by the Developers on the team. Most often, this happens during the Backlog Refinement event.
INVEST
The INVEST principle tells us more about writing good user stories. According to that principle, each user story should be:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Whether or not all user stories should follow the same template has been a heated debate in the agile community.
Ron Jeffries, co-creator of the Extreme Programming (XP) framework and one of the 17 co-signers of the Agile Manifesto, explains on his blog that the important thing is not about how to write user stories, but how to communicate them to and converse about them with the team of Developers. For that, a useful practice is “Card, Conversation, Confirmation” (see three practices below in this list).
User Story Mapping
User story mapping is the practice of grouping user stories under epics and/or themes based on the similarities between them. Usually, an agile team does user story mapping during the Backlog Refinement meeting or at dedicated working sessions or workshops.
Acceptance Criteria
Acceptance criteria are the conditions that a backlog item (user story, epic, or theme) has to meet before it can be considered done.
Acceptance criteria are written as short and concise statements that act as test scenarios for the software product that’s being built. Usually, they’re written as bullets under a user story. These test scenarios then inform the work of the Developers and Testers on the team, who use them to build test cases for proving them correct or not.
For example, let’s create a user story specifically for this agile practice in my list and let’s assign a set of acceptance criteria for it. If each agile practice in this list was based on a user story, how would the story and acceptance criteria look like?
| User Story | As a Product Owner, I want to understand what acceptance criteria are, so that I can start adding them to my user stories. |
| Acceptance Criteria | The post contains a definition of what acceptance criteria are;The post provides an example set of acceptance criteria;The post shares best/good practices for writing acceptance criteria. |
So far, so good. If I were a tester (or an Editor, in this case), I would use this user story to determine whether or not this section of my blog post can be considered done. Right now, the third acceptance criterion (“The post shares best/good practices for writing acceptance criteria.”) is unmet.
A good practice for writing acceptance criteria is to use the so called “Given-When-Then” or “GWT” format. Here’s how it works:
- Given (some context)
- When (the user takes some action)
- Then (something observable and testable happens)
For example, “Given the user is on the homepage, when they click on the title of a blog post, they will be redirected to the URL of that blog post in the same browser tab/window.”
Software tools for agile teams that practice Behavior-Driven Development (BDD), such as Cucumber, RSpec, and JBehave, also encourage the use of the GWT format. BDD is also known as “Specification by Example.”
User Story Mapping
User story mapping is the practice of grouping user stories under epics and/or themes based on the similarities between them. Usually, an agile team does user story mapping during the Backlog Refinement meeting or at dedicated working sessions or workshops.
Estimation & Forecasting Practices
Story Points
Estimation helps agile teams and their customers to make better-informed plans (while not forgetting that any estimates are indicative and all plans are subject to change). To estimate the effort needed to complete a piece of work, agile teams use story points.
Story points are an indicative and relative estimate for the effort required to complete a work item on a product backlog. Indicative as all estimates, in their nature, are inaccurate. Relative as, instead of hours, story points use Fibonacci numbers (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …, n).
When you estimate a sub-task, task, user story, epic, or theme in story points, you assign a relative value using a Fibonacci number. For example, a user story assigned 1 story point is estimated to take twice as less work than a user story assigned 2 story points.
Only the people doing the work can estimate the work. Their estimates are based on their subjective judgement, individual or as a team, about:
- The amount of work
- The complexity of the work
- The uncertainty and ambiguity of the work
Work items that take less technical time, are not really complex to complete, and are fairly certain and unambiguous take the least time. Work items on the opposite end of the spectrum on some or all of these criteria take the most time to complete.
As a rule of thumb, newly-formed teams working on new products and/or with new technologies make less accurate estimates. Established teams working on existing products and/or with known technologies make more accurate estimates. The same is true for teams who are solving novel problems vs. problems that they’ve solved before.
In any case, estimation is an indicative and relative practice; it is almost never 100% accurate. Estimation is comparable to driving. To keep the car moving in a straight line, you don’t need to know its exact distance between the left and right lanes of the road. Instead, you as the driver make an informed but intuitive judgement that allows you to steer the car relatively straight.
Planning Poker
Planning poker (also called “Scrum poker”) is an agile game for consensus-based team estimation.
In planning poker, the members of an agile team make estimates for each work item by playing numbered cards face-down on the table. They then reveal their cards and discuss their estimates.
The game is useful to surface discrepancies in estimation and eliminate peer pressure to come up with similar estimates. This way, all members of the group can clearly see when there are big differences—and have a discussion that helps them to come to a shared definition.
Planning poker was created by Mike Cohn, whose company Mountain Goat Software built PlanningPoker.com, a web-based tool that helps agile teams to play the planning poker game. Cohn is also one of the founders of Agile Alliance, an organization created to promote agile ways of working across geographies and industries.
Elephant Carpaccio
Elephant carpaccio is an agile practice in which the team breaks down a large piece of work (the elephant) into smaller chunks (the carpaccio slices) that they can deliver in a single iteration. The practice was invented by Alistair Cockburn, American computer scientist and co-signer of the Agile Manifesto.
Say that a team has a velocity of 21 story points per sprint. The team identifies the need for a new feature that they estimate at 34 story points. To practice elephant carpaccio, the team breaks that user story down into multiple user stories and re-estimates the time to get each of these new, smaller user stories done.
In an agile approach to building products, the amount of work done should be minimized to only what’s necessary to deliver value. And each work item should be small enough to be part of the backlog for a single iteration (consequently, this means small enough to be able to plan alongside other work items in that iteration’s backlog).
The smaller the work, the lower the risk of getting it wrong. After all, agile takes an empiric approach to delivery. And, in an empiric approach, the only way to tell if a feature is truly going to deliver value or not is to build it, release it, and get it in the hands of the customer.
Velocity
Velocity in an agile project is a measure of the work completed in a single iteration. Since most agile teams estimate effort in story points, velocity is usually measured in story points per iteration.
For example, a Scrum Team works in 2-week sprints. In their latest sprint, they completed 21 story points. Their velocity is 21 story points/sprint.
When planning their next sprints, some teams use the velocity from their previous sprint as a limit for how much work items they can commit to. Others calculate the average velocity from multiple sprints. For example:
| Sprint # | Velocity | Average Velocity |
|---|---|---|
| Sprint 1 | 13 | 13 |
| Sprint 2 | 21 | (13 + 21) / 2 = 17 |
| Sprint 3 | 13 | (13 + 21 + 13) / 3 = 15.6 |
In our example, the team using average velocity will approximate their velocity to 16 and use it as the limit for the amount of work that they can commit to in Sprint 4.
Burndown Chart
A burndown chart in an agile project is a visual representation of how much work is left to do vs. how much time is left to do it in a given timebox (like an iteration in XP or a sprint in Scrum).
Burnup Chart
A burnup chart in an agile project is a visual representation of how much work has been completed vs. the total amount of work planned in a given timebox.
Burndown Chart vs. Burnup Chart
The burndown and burnup charts are like the two sides of the same coin; each represents the actual progression of an agile team’s plan vs. the original plan for a given timebox. However, the burnup chart accounts for and visualizes any extra work added to the timebox after the original plan was made—making it highly useful in projects and iterations where scope change happens often.
Sustainable Pace
The eight principle of the Manifesto for Agile Software Development says, “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Simply said, people sponsoring, working with, and working in an agile team understand that Rome wasn’t built in a day (and it wasn’t built in a two-week iteration either). Which is why they take a long-term and systemic view to their organization, team, and product.
Rushing to deliver more than what is sustainable for one sprint (or multiple sprints in a row) destroys morale and creates technical debt. Like credit card debt, bad morale and technical debt only grows bigger over time—eating up more and more of the team’s desire and ability to deliver items of higher value.
Trying to increase a team’s capacity in the short term by adding new team members will only decrease it. These new team members need to be onboarded—and onboarding them will take up the time of the more senior team members who will lose capacity and focus as a result.
The mature agile practitioner knows that the only way to solve problems is for the long term; all other solutions are merely workarounds. There’s a time and place for each, but trying to fix a problem with a workaround is a sure-fire way to build risk into the project and cause headaches for sooner rather than later.
Technical Practices
Architectural Runway
The Architectural Runway is a concept from the Scaled Agile Framework (SAFe). It consists of all the IT infrastructure, source code, and components necessary to deliver useful and valuable software to customers without excessive redesign, rework, and delays.
The runway supports the continuous flow of value through the Continuous Delivery Pipeline (CDP), an umbrella term for the tools, activities, workflows, and automations required to ship functionality, from an architectural and development point of view, from an idea to the production environment.
One way to think about the Architectural Runway is like a technical backlog, of sorts, that paves the way to a stable, scalable, extensible, and operable/maintainable product.
Like a Product Owner of a Scrum Team or a Customer of an Extreme Programming (XP) team is ultimately accountable for the Product Backlog, the Software Architect of an agile team is ultimately accountable for the Architectural Runway.
Like the Product Backlog Items on a Product Backlog are called user stories, the items on the Architectural Runway are called “enablers.” An enabler doesn’t necessarily deliver business value directly, but it enables a team to deliver business value in a better way indirectly.
Simply said, the Architectural Runway contains the work that a team needs to do to be able to deliver a better product in a better way, whichever their definition of “better” is in the specific case.
Spike Solutions
As a team works to deliver customer value, every so often they come across technical or design problems that they need to solve.
The spike solution is a concept from the Extreme Programming (XP) framework. It’s a very simple solution that’s built to answer a very specific technical or design problem, enabling the team to identify an optimal implementation approach.
Most spikes are created as “throwaway prototypes.” Their purpose is to help the team identify the best way forward. Once they’ve served that purpose, the team (and the organization that’s sponsoring them) are okay to throw it away and move on to a better implementation using the lessons learned and insights gained.
One frequently asked question about spikes is how they relate to enablers. Spike solutions and enablers come from two different agile frameworks (XP and SAFe, respectively). However, a spike solution is a type of enabler, and thereby one of the items on the Architectural Runway.
Coding Standards
In agile, the members of a development team write code based on agreed-on coding standards.
This is an agile development practice that comes from the Extreme Programming (XP) framework. Using it, an agile team ensures the consistency and the quality of code, no matter what level of context or experience each team member coming in or going out of the team has.
Some teams keep a set of coding standards as simple as several bullet points that reference the naming convention, coding style, and patterns that Programmers should use. Others are more specific and elaborate in their definitions. The best coding standards come from the team and the people doing the work themselves and follow the practice of “just enough documentation.”
Unit Testing
In high-performing agile teams, programmers write unit tests before they write code. Starting with unit tests helps the programmers to consider what really needs to be done. When the specification is written as executable code, there is no room for misinterpretation.
Unit tests are typically automated tests by which single units of source code (i.e. a line of code, a method, or a class) are checked, so as to determine whether or not they’re fit for use. As a rule of thumb, most developers try to keep their units simple and their tests small. Simple units are harder to get wrong and smaller tests are faster to run.
Unit Test Coverage
Most development teams that write unit tests and/or practice Test-Driven Development have the practice of measuring unit test coverage.
Unit test coverage stands for the amount of source code that’s covered (or not covered) by unit tests. It is usually measured in percent.
Low unit test coverage is an indicator of a problem within the team’s approach or behaviour to coding standards. It could indicate that a team is missing technical know-how and/or has a low degree of development maturity and process discipline.
Test-Driven Development (TDD)
As an essay on Agile Data says, Test-Driven Development (TDD) “completely turns traditional development around.”
Test-Driven Development (TDD) is an agile development practice, in which the Developer writes a unit test before they write a single line of code that this unit test is intended to check.
Subsequently, the test fails. The Developer then begins to write just enough code and keeps the code as simple as possible, refactoring it until the unit of code (which can be a line of code, a method, or a class) passes the unit test.
This practice is repeated for every unit of source code, which helps the team to accumulate a code base with the highest useful degree of unit test coverage over time.
Behavior-Driven Development (BDD)
Behavior-Driven Development (BDD) is a development practice that allows agile teams to drastically shorten the feedback loop by producing specifications in a way that they can be automatically checked against the actual behavior of the product increments.
It takes four steps for an agile team to practice Behavior-Driven Development (BDD):
- A user story is written as a self-contained specification for work that needs to be done to deliver customer value;
- The team has a conversation around the test scenarios that they can test against to determine if and when the user story is complete;
- They document these test scenarios as acceptance criteria in a standardised format, usually the Given-When-Then (GWT) template, that can be imported in a system for automated testing;
- Once the user story and acceptance criteria are implemented, the automated tests are run to determine if the increment is fit for use.
As a best practice, agile teams can implement both Behavior-Driven Development (BDD) by specifying acceptance criteria in an automatable format and Test-Driven Development (TDD) by creating unit tests before writing a single line of code on the same project.
BDD results in products that deliver exact value to their customers. TDD ensures that any bugs on these products are spotted and fixed early in the development of the product. Combined, both result in effectiveness, efficiency, and higher levels of customer satisfaction.
Pair Programming
When two programmers work on one computer, they pair program. One is usually doing the coding (often referred to as the “driver”) and the other is observing and giving directions (the “navigator”). As they work on a single workstation to build the same piece of the product, they swap roles every few minutes.
Other Technical Practices
- Using Class, Responsibilities, and Collaboration (CRC) cards to design the solution architecture of the product as a team (XP);
- Integrating code early and often (XP);
- Using Solution Context to identify the critical aspects of the operational environment of a software product (SAFe);
- Evolving the Continuous Delivery Pipeline (CDP) as a technical container that consists of continuous exploration, integration, and deployment (SAFe);
- Capturing Non-Functional Requirements for every work item on the product backlog (SAFe);
- Supporting emergent architecture, or just enough architecture design that comes from the team (Charles Bradley).
Conclusion
This concludes my list of agile practices. I’ll be keeping them up to date, so put this post in your browser’s bookmarks and feel free to visit it every so often to check for updates.
Which agile practices are your favorite? Which ones are missing in the list? Let me know in the comments below.
