Agile Engineering Best Practices

Agile engineering preaches being efficient and responsive to change in order to develop the best product. Learn its best practices and how they can enable you to create a rapid, continuous development cycle.

In just about any modern tech startup or enterprise company, software development teams adopt what’s known as an agile engineering process. In agile engineering, teams constantly develop and iterate on prototypes in response to a steady stream of customer feedback and demands. This contrasts with the more traditional approach of predicting customer preferences and developing a single prototype to try and address them all.

The agile approach is a must in a fast-paced industry like software engineering, but it can be applied to many other fields as well. Agile teams are able to quickly make decisions and develop features that give the greatest customer satisfaction. They also take on less risk with each decision: because the feedback loop occurs so frequently, agile teams can easily pivot to a different decision if they receive a negative response from customers.

Overall, teams that adopt an agile mindset save more time and money in the long run. This article will list all of the most essential agile engineering best practices that your teams must implement in order to maximize efficiency in today’s ever-evolving tech industry.

The Agile Manifesto

Tenets outlined in the Agile Manifesto inspire modern agile engineering processes. Briefly, here are the four tenets.

Individuals and Interactions over Processes and Tools

While processes and tools are necessary, they can’t by themselves determine customer needs. In some cases, strict adherence to processes and tools may also delay the development process. By placing a higher value on individuals and interactions, engineering teams put themselves in a better position to respond efficiently to business needs.

Working Software over Comprehensive Documentation

“Comprehensive documentation” refers to anything used to keep track of the development process, such as technical specifications and testing plans. While agile engineering does attribute some importance to project documentation, it should never get in the way of the ultimate goal: to produce working software.

Customer Collaboration over Contract Negotiation

Your customers play a big role in agile development. In many ways, your customers are your biggest stakeholders. As such, it’s paramount for engineers and product managers to collaborate with customers on details such as technical requirements and feature requests.

Responding to Change over Following a Plan

Agile engineering got its name from the word “agile,” which Merriam-Webster defines as “marked by ready ability to move with quick easy grace.” Change is inevitable in business. Agile engineering teams are expected to embrace change and respond accordingly, rather than stick stubbornly to a plan.

Best Practices

Based on these four tenets, agile engineering teams have created and fine-tuned various practices that have become commonplace in most tech companies. A specific type of agile methodology known as scrum comprises four best practices that all teams adopt.

Sprint Planning

A sprint is one of the most basic building blocks in the agile philosophy. Sprints are defined by a set amount of time and a set number of tasks. During the sprint, scrum teams work to complete each task before the sprint ends. Each team defines its own sprint length, but sprints typically last from two to four weeks.

Sprints usually begin with a sprint planning meeting. During sprint planning, tasks for the sprint are chosen, sized, and then assigned to individuals. Each sprint planning meeting involves the following cast:

• Product managers (or in some cases software managers) are responsible for choosing tasks for the sprint from the project backlog. As they are the primary liaison between the customer and the engineering team, they have the best knowledge of various business priorities and choose tasks accordingly.
• Software engineers work together to estimate the effort required for each task. They distribute the work evenly among the team.
• The scrum master facilitates the sprint planning meeting. The scrum master may be the product manager, software manager, program manager, or a software engineer.

In a good sprint planning meeting, the team emerges with a clear understanding of the sprint objectives, as well as the items they are tasked with. These items are usually organized into a sprint board (or scrum board) for status tracking.

Job Sizing and Estimation Techniques

In order to plan a successful sprint, backlog tasks must be sized appropriately. Underestimating tasks can have negative cascading effects on future sprints, which ultimately delays project delivery. This can also hurt team morale.

Agile engineering teams have come up with several estimation techniques for sizing a task.

Story Points or Task Points

Teams can define a story point in any manner they like. On some teams, a story point loosely translates to a day of work; other teams may define it as half a day of work or even an hour.

In an ideal sprint, every engineer has enough story points for the entire sprint. For example, for a two-week sprint, where one story point equals one hour of work, each engineer should be assigned eighty points of work.

As the team undergoes multiple sprints, they may refine their definition of a story point. For example, suppose a team consistently underestimates the effort required for tasks. If their previous definition of a story was one hour, they might redefine it to be two hours instead. In this case, each engineer would then be assigned forty points of work per two-week sprint.

Fibonacci Estimation

Teams that use story points often use the Fibonacci estimation technique. Rather than use any arbitrary number to size a task, teams use numbers from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, and so on). The Fibonacci numbers are adequately spaced from each other and provide a good proxy for story points for tasks of varying complexity. This can help provide more realistic estimates, especially for larger tasks.

T-Shirt Sizes

A somewhat more abstract way to estimate tasks is by using T-shirt sizes (XS, S, M, L, XL). As with story points, teams can define each T-shirt size as they like and refine this definition over time. For example, an XL T-shirt-sized task might take up the entirety of a two-week sprint, while an XS T-shirt-sized task might take half a day or less.

Planning Poker

No matter the estimation technique, teams should also consider using scrum planning poker to size their tasks. In planning poker, each attendee offers their own estimate for a task and reveals this estimate at the same time to all other attendees. This makes the estimation process collaborative and ensures that one person’s estimate doesn’t overshadow anyone else’s.

Daily Stand-ups

Throughout a sprint, teams will hold a daily stand-up (also known as a daily scrum). Stand-up is a short meeting, usually no longer than fifteen minutes, that occurs every day at the same time. Its primary purposes are to keep everyone up to date on the status of the sprint and to identify any current blockers.

During stand-up, teams usually stand in a circle. The scrum board is displayed for everyone to see. Each developer gives a quick status update on their sprint items, focusing on the following three points:

• What I worked on yesterday.
• What I’m going to work on today.
• What issues, if any, are currently blocking me.

As developers give their updates, they may move their items on the sprint board across different progress stages (input queue, in progress, testing, in review, pending, complete). In addition, stand-up updates should be quick and to the point. If there are topics that need additional discussion, developers can huddle after everyone has given their updates.

Retrospectives

At the end of a sprint, agile teams will hold a retrospective. In this meeting, the team reviews the sprint and discusses the following:

• What went well? Always include positives in a sprint retrospective. Each member should get a chance to share what they thought went well during the sprint, and commend other team members when appropriate.
• What obstacles arose? Sprints don’t always go smoothly! Sometimes, tasks take much longer than anticipated to complete, and some need to be punted to the next sprint altogether. It’s important to identify any risks or blockers that caused this to happen. Doing so immediately after a sprint can help determine whether project timelines are still realistic.
• What can we improve in the next sprint? This is perhaps the most important question. In order to set up future sprints for success, everyone should share practical ways to improve the team’s processes and the project as a whole.

To better facilitate discussion, scrum teams like to use sticky notes along with a whiteboard (or virtual board). The whiteboard is divided into three sections, where each section is dedicated to one question above. The group then spends the first ten minutes of the retrospective filling out sticky notes and placing them in the appropriate section. This gives everyone an equal chance to get ideas on the board.

After discussing each sticky note, teams usually vote on the best ones. This helps define concrete action items to commit to for the next sprint.

Conclusion

Agile engineering is a term that is used often in the software industry, and for good reason. It’s a philosophy that preaches being efficient and responsive to change in an effort to develop the best product that suits customer needs.

From this philosophy arose the scrum methodology. This article introduced four best practices that all scrum teams implement—sprint planning, job sizing, daily stand-ups, and retrospectives. Together, these best practices create a rapid, continuous development cycle that’s necessary in an industry like software engineering.

Status Hero is a tool that supports the agile methodology by changing the way teams approach daily stand-ups and other meetings. Status Hero uses periodic prompts and data from project management tools like Jira and Asana to automate generation of team-wide status reports. This can help your team eliminate time-consuming meetings to focus on more important issues instead.

By Alexander Yu. Alexander is a technical writer at AWS by day and a freelance writer by night. After completing his BS in electrical engineering and computer science from UC Berkeley, he became a software developer at AWS for almost three years before transitioning into technical writing. He lives in Seattle with his dog Yuna.