How Agile Teams Fulfill Requirements – The Ultimate Agile Guide

Everywhere you look, you’re surrounded by software. For example, the number of people using computers (powered by software) in 2008 stood at 1 billion globally. Fast forward to 2022, and there are 7.26 billion smartphone users worldwide. And more computers mean an increased demand for software development.

The demand for software development has skyrocketed in recent years, and more companies than ever before are investing time and resources in development projects. As a result, software development not only survived the pandemic unscathed, but it thrived and continues to thrive today.

However, not all software development methods are created equal. Today, software developers are increasingly looking for faster and more efficient ways of making the next generation of apps. So, for example, the once-popular Waterfall method (where all tasks are placed on a list and ticked off one by one) is falling out of favor. Instead, developers are choosing to implement Agile in-house for a more efficient approach to project management. With this in mind, let’s dive into the details of the agile method and the best practices for managing requirements in agile projects.

What’s Agile, and How Do You Implement It?

The groundbreaking Agile Manifesto, which puts forward a list of principles for a better way of developing software, was born out of the need to streamline the software development process. The manifesto offers four core values and 12 principles aimed at discouraging inefficient practices like excessive meetings, rigid adherence to process, and heavy documentation.

When we talk about efficiency in software development, we’re really talking about getting more (a high-quality product) while using fewer resources (time, money, energy). So, when we talk about agile being more efficient than traditional methods, we aren’t talking about writing faster code but doing more valuable things. Essentially, agile allows developers to do less overall but still achieve better outputs.

In agile, the agile development team isn’t just a group of people who robotically execute actions like writing and testing code. Instead, it’s a team of people with their own expertise, and ability to think flexibly and apply knowledge to other areas. The interpretation and application of knowledge is a critical aspect of agile, and it goes beyond limiting team members to narrow fields of expertise. In simple words, agile development team members strive for cross-disciplinarity over narrow mastery. So, what does this mean in practice? It means that agile developers are constantly involved in activities not related to writing code.

Another way agile stands out from other approaches is in its hierarchy, or lack thereof. Agile methods are focused on self-organizing teams, collaboration, and relative equality between all team members. This means that while agile development teams might have a project leader, that person is not a manager in the traditional sense. They might be a source of knowledge for the project, but the responsibility for the project’s success doesn’t lie solely with them - instead, it’s collectively shared among all team members.

What’s Needed to Implement Agile?

Okay, so you like the sound of agile, but how do you transform into an agile team with an agile mindset?

• Abolish hierarchy within the team while ensuring all members can share equal responsibility for the project’s output.

• Focus on ensuring that each stage is guaranteed to bring something new to the product.

• Familiarize yourself with the Agile Manifesto and its core values and principles. You can read more about the Agile Manifesto here.

The Scrum Framework

Agile software development is an umbrella term for multiple different frameworks and practices that follow the values and principles expressed in the Agile Manifesto. So, several different agile project development methods exist. Scrum, Crystal, Feature-Driven Development (FDD), and the DSDM method of dynamic system development are common examples of agile frameworks. However, Scrum is the most popular of these, so that’s what we’re going to be focusing on here.

Scrum is used by 83% of companies, and its dominance over other methodologies is primarily due to its capability to help teams move and learn faster. Scrum provides a clear rhythm that helps achieve predictable results, making it a highly reliable methodology. This rhythm is achieved by a structure of sprints and meetings that include:

• Planning: Where sprint priorities are set.
• Commitment: Where the agile development team reviews tasks and determines what can be accomplished in the next sprint.
• Daily meetings: Where team members report status changes and discuss strategies.

At the end of each sprint, there is a product demonstration so the customer can evaluate functionality and progress. Then, the team holds an internal meeting to discuss the sprint’s results and make any necessary process adjustments. And then it’s rinse and repeat!

Now, let’s dive a little deeper into the core components of Scrum.

Sprint Planning (Sprint Backlog)

In Scrum, team members perform tasks as they appear on the product backlog. A product backlog is an emergent, ordered list of prioritized features needed to improve the product. But how do you decide which items make it onto the backlog? Typically, the user story format is favored here.

User stories describe the required functionality from the perspective of a user, for example, “As a (user), I want (function), So that (purpose).” This is essentially the ‘who?’, ‘what?’ and ‘why?’ of the change.

You can read more about how to plan the product backlog and what you should pay attention to.

One common question tends to crop up here: “how detailed do the tasks need to be and who evaluates them?”. Luckily, there’s a straightforward answer to this question. Task content should be detailed and elaborate enough so that the Product Owner is confident that performing these tasks will bring value to the users and the team and estimate the labor involved during the planning stage. Task assessment is vital in deciding what ultimately ends up in each Sprint and what doesn’t.

But after we’ve assessed the tasks, how do we decide which items come together in which Sprint? First, team members need to ask, “Why is this Sprint valuable?”. To answer this question, the Product Owner needs to express how the Sprint will offer more value and usability to the product. The agile development team then collaboratively defines the Sprint’s purpose and explains why it will add value to end-users.

Next, the team needs to decide what exactly can be done in the current Sprint. In this stage, agile developers and the Product Owner collaborate to determine which elements of the Product Backlog should be included in the current Sprint. In addition, the team needs to refine the items and make sure everyone understands them sufficiently enough to get started.

The next thing to decide is how exactly the work will be done. For this, developers need to look at each item and determine the work required to create an increment that meets the Readiness Criteria. How? By breaking down the Sprint Backlog elements into smaller tasks lasting no more than one day.

How to Estimate Workload

You can either estimate workload using man-hours or conditional units called Story Points. With man-hours, you take into account the total resource hours of the team, extra commitments or leave, and how long each task will take. Doing this gives you a much clearer picture of what exactly can fit into the current Sprint. It’s important to set reasonable estimates without striving for excessive accuracy here.

By contrast, Story Points are units of measure for expressing the overall effort required to fully implement a product backlog item. When determining the points, you use factors like work complexity, amount of work, and risk or uncertainty. It’s essentially a relative estimation tool that empowers teams to become better at workload estimation over time.

Traditionally, agile software teams favored man-hours, but today, teams are increasingly using Story Points because of the benefits they offer. Namely, Story Points reward teams for solving problems based on difficulty rather than time spent. This keeps the team focused on adding value, not spending time.

Daily Scrum/Stand-up

The Stand-up, sometimes also referred to as Stand Up, Daily Scrum, Kanban Meeting, or simply Daily, is a regularly held short meeting for Agile team members. The goal is to go over important tasks, synchronize all participants, and provide transparency of the work process.

The idea here is that stand-ups help maintain an effective and productive team. Additionally, stand-ups help strengthen the bond between the dedicated development team members. The more time team members spend together, the more they’ll be comfortable speaking up and offering feedback. Open communication is vital to success in agile.

Stand-up Objectives

• To prepare for and plan for the day’s work.
• Evaluate the previous day’s work.
• To share information and plans with colleagues.
• To get information from colleagues that can be useful during the working day.

It’s important that stand-ups stay on track and that each team member only shares valuable information. This is partly why participants remain standing during the meeting - the discomfort of standing for long periods is intended to keep the meetings short and the content concise.

Stand-ups are also crucial in finding the pitfalls in your development approach. For example, you might find that one of the tasks you discuss is deemed challenging and may potentially take several weeks to complete. This is a sure sign that you’ve made a mistake because any enormous task should be divided into subtasks so you can easily track their progress and results.

So, how should agile team members inform their team during a Stand-up? Like this:

My activities for yesterday were:

1. Of the activities I planned yesterday, I did this (the emphasis here goes to what I did, not what I’m doing)
2. Of the activities I had planned to do, I didn’t do this or didn’t finish that because…
3. I ran into problems, so…

My activities for today are:

For today, I plan to do this first and this second. I plan to finish this activity.

Additional helpful feedback:

What do I think is the team’s likelihood of reaching the Sprint Goal?

What Does the Perfect Stand-up Look Like?

1. Stand-ups Always Start at the Same Time Every Weekday

Ideally, stand-ups should be 15 minutes long and no longer. They should also take place at the same time every weekday without fail. Put simply, you don’t wait for latecomers - keeping to a fixed and uncompromising schedule quickly disciplines the team.

During the meeting, it’s important to discuss all updates and identify any factors blocking progress. Additional details can then be addressed in person, in a chat room, or in a separate meeting.

2. Dedicated Development Team Members Must Come Prepared

Stand-ups should have a fixed format that becomes second nature to the team. For example, you can choose your own format, like three-set questions each participant must answer. This is crucial in ensuring that everyone understands why they’re there and what’s expected of them. By the time the stand-up concludes, its goals should be achieved: prioritize tasks, make decisions and assign next steps, synchronize the team, etc. In addition, having a fixed format helps eliminate unrelated topics and topic drift.

3. Everyone Must be Equally Engaged

No one should dominate the meeting nor sit quietly on their laptop in the background. For stand-ups to be valuable, everyone must be engaged and participate. Each participant briefly shares essential information, and then a short discussion can follow. And crucially, no-one’s speaking time should exceed two minutes. Sticking to this limited but fair time requirement helps instill brevity and conciseness. Each team member’s report should be well structured and informative, and members should put just as much effort into speaking as they do listening. If someone has a question about the information they have heard, there is no need to interrupt or start a discussion; they can note that they want to discuss the details after the meeting.

4. Stick to the Structure

Stand-ups are designed to be informal but not unorganized. In other words, you must stick to whatever structure you decide. Of course, the structure you ultimately pick will depend on your approach and the nature of the project. Your stand-up could be a discussion. For example, “what has been done since the last meeting?”, “who is working on what right now?” and “what are the current blockers and challenges?”. Alternatively, you can go by tasks, where each team member shares updates on any tasks they’re involved in completing.

For the first few stand-ups, it’s best to have a “dark moderator,” someone who won’t explicitly let themselves be shown as “in charge” but will keep an eye on the structure and rules of procedure.

Sprint Review (Demo)

The sprint demo is a chance for the team to celebrate their accomplishments, get feedback about their work, and keep stakeholders up to speed with product development progress. The stakeholders also have the opportunity to provide feedback about whether the product meets their expectations, solves the tasks, and adds value.

Why is this feedback necessary in effective agile project development? Because highly complex systems with many moving parts and bodies on the ground need to have their veracity tested. Or in simple words, customers don’t know what they want, so it’s the team and stakeholder’s job to find what really adds value. The words of Henry Ford, the man who brought cars to the masses, ring true here “If I had asked people what they wanted, they would have said faster horses.”

Feedback, both negative and positive, should be collected and shared with the entire team. Sadly, negative feedback often takes precedence over positive feedback because it feels more urgent and actionable. However, it’s crucial for the team to feel their successes, too - it boosts morale and strengthens bonds between members of the dedicated development team.

We recommend that all (or as many as possible) developers conduct the demonstration, rather than just one person assigned by the team. Why? Group demos increase the level of team responsibility and avoid distortion of the message, which can impact the stakeholder’s feedback.

It’s also important to note that the sprint review isn’t a simple reporting event. Instead, it’s a constructive and candid dialogue between developers, the Product Owner, and stakeholders.

The Product Owner is responsible for collecting the feedback on goals and communicating it to the team.

So, what exactly happens in a sprint review?

• The Scrum team demonstrates the results of their ongoing work to stakeholders.
• The team discusses their progress towards achieving the product goals.
• The team and stakeholders analyze what was accomplished in the sprint and any factors affecting the product.
• All participants decide what to do next.
• The product backlog can be adjusted as needed to reflect new opportunities and obstacles.

It’s a good idea to get all the feedback before the Retro session (next section), so the team can discuss it there.

Sprint Retrospective

The sprint retrospective is a recurring meeting held at the end of a sprint to discuss what went well during the previous sprint cycle and what can be improved for the upcoming sprint. Essentially, it’s an opportunity for the Scrum team to inspect itself and create plans for moving forward. This kind of self-reflection is critical for continuous improvement and is integral to the success of any agile method.

The retrospective is always directed inside the team, and any discussions or decisions are for the team itself. In other words, it’s a purely internal meeting where no outsiders are welcome.

Retrospectives should be done regularly. And more generally, everything in Scrum should be done regularly. This means planning, review, and retrospective. The “power” of the agile methodology is in its ability to transform a sometimes chaotic and unpredictable creative development process into a predictable and organized one.

The retro should take place after the sprint review. Why? So that team members can discuss how well the review went, including how successfully the results were presented to stakeholders. Some teams are often tempted to hold the sprint review and sprint retrospective together to save time, but this isn’t a good idea. The meetings work best if they’re kept separate so that only the relevant parties are in attendance and so the purpose of the meeting is clearly understood by everyone involved. It should also be held before moving on to the planning stage for the next sprint. This is because you might discuss some items that inform your strategy for the next sprint.

A typical retrospective involves team members answering the following questions:

• What in the past sprint has been good and helped you work?
• What hindered you from working?
• What or who could help you work better?

With people increasingly working in a virtual setting, retros are often done with a shared screen with two or three notepads or one MS Word or Confluence screen with three fields. Typically, these fields are dubbed “pluses”, “minuses”, and “actions”.

Useful Practices for Getting the Most Out of Your Retrospective

The general rule for sprint retrospectives is to allow 45 minutes of meeting time for each week of sprint length. So, for example, a two-week sprint would require a 1hr30 retro meeting. But crucially, these meetings are also limited to a maximum of three hours.

However, if the whole team simply sits for three hours in the same room staring at each other, they’re not going to see much process improvement, right? Similarly, if we spend three hours firing off criticisms at other people, we also won’t get very far. So, how do you maximize your time and ensure you’re getting the most from your sprint retrospective?

• Keep it positive and focused on improvement. You should avoid saying things like, “this was good, and this was bad”. Instead, you should say, “this was good, but I was hindered in this area, and this is how I think we should fix or improve it”.

• All team members should be involved. It’s crucial that all team members be involved, but this doesn’t necessarily mean you should encourage everyone to speak up. Instead, you can invite everyone to write talking points about the good, any obstacles, and ideas for improvement on post-it notes. Then, they can post the notes to the board for discussion.

• The end result should be an improvement plan. Highlight all the most important takeaways so they can inform the next sprint. You should arrive at the most important points by taking a vote rather than through discussion. Crucially, important points should be assessed not just on their rational importance but also on the emotional attitude towards the ideas.

Bad Practices (Things to Avoid)

• Not giving it the time it deserves. Don’t be tempted to cut corners by holding a half-hour retrospective that serves no actual function other than saying, “here’s how great and friendly we are”. A short retrospective is a clear sign that the event is just for show, and you’re not getting the benefit of a full-blown meeting.

• Using the same boring format. If your retrospectives are too fixed and formal, they will quickly become boring to participants, and everyone will switch off.

• Airing personal grievances. The retrospective isn’t a forum for criticizing your team members with the protection of a larger group. Instead, you should discuss any issues with people individually, so they don’t feel publicly attacked.

• Bringing up the same problems without taking action. If you bring up the same issues every retro without solving them (or making tangible steps to solve them), the team will quickly learn that it’s pointless to express these ideas because nothing will be done. The problems will still be there, but they’ll no longer be discussed.

Backlog Refinement (Grooming)

Backlog refinement, formally known as backlog grooming, is a recurring event aimed at making improvements to the product backlog. But crucially, it’s important not to merge backlog development with sprint planning. In sprint planning, we already have a list of prepared tasks, and this allows us to focus only on story implementation issues and the composition of tasks for the next iteration. By contrast, refinement is a preliminary step where you can prepare a set of tasks to plan into the work if needed.

The Product Owner, some members of the Scrum team, and some stakeholders (if their presence would be useful) take part in this meeting. Here, the Product Owner takes the lead in organizing the meeting, setting the goals, and detailing the agenda. It’s also important to limit the number of stakeholders who participate simply because too many participants reduce overall effectiveness.

At its core, the backlog refinement meeting aims to discuss the current backlog and identify and propose actions to optimize it. This may include:

• Writing new user stories
• Deleting irrelevant user stories
• Reassessing priorities for tasks
• Adding new features, prioritizing and evaluating them
• Improving and reprioritizing previously described user stories
• Breaking some user stories into smaller ones
• Revising testing criteria
• Analyzing time and individual scores for specific backlog issues
• Adjusting scores in light of new data, etc.

The end result of refinement is a healthy-looking backlog, which in practice means:

• There are enough tasks at the top of the backlog for 2-3 sprints
• User stories are understood by all team members
• Stories are evaluated by the team (make the items detailed, relevant, and estimated)
• User stories are sized to implement several of them in a single sprint

For sorting backlog elements, you need to consider Value and Effort. Value is a measure of how much value the task brings to the customer, while Effort counts the resources necessary to complete the task.

Refinement is crucial in ensuring that the requirements are clarified, and user stories are prepared ahead of future sprints. By the time the team comes to the next iteration, they already have a well-analyzed and well-defined set of stories.

Best Practices for Managing Requirements in Agile Projects

Your success in agile projects largely depends on your approach, which includes adherence to general best practices. With this in mind, this is what you should be focusing on:

• Reviewing Requirements Collaboratively: Collaboration allows for better knowledge transfer and encourages individuals to make a greater contribution to a common goal. No one is left on their own, and efforts shouldn’t be duplicated if you work collaboratively.

• Visualizing agile project requirements: People are visual creatures, so using visuals rather than text can help accelerate team members’ understanding of the situation.

• Analyzing the current state and understanding future gaps: Agile teams often spend too much time “in the moment” and not enough time identifying gaps that could be critical in the future. The future should always be a key consideration, and the project manager should help make a plan to get to the desired state smoothly.

• Keeping documentation organized: Unorganized documentation can lead to missed opportunities to add value and longer project timelines.

Wrapping Up

Are you about to start working with an experienced agile development team or want to learn more about agile application development services? If so, you’re in the right place. We can help with agile implementation consulting for your product. Get in touch today to speak to our Agile and Scrum project management experts. We look forward to hearing from you!