7 Agile Best Practices You Should Know

Intro

The Agile Manifesto didn’t prescribe daily stand-up meetings or two-week iterations. Instead, it offered a set of core values that put some things over others.

In the previous article - What is Agile and why it works so well?, we wrote about what Agile is in general and why it works so well for our organization. Now, get acquainted with the 7 Best Agile Practices that help our teams deliver excellent results.

Agile best practices at Sunscrapers

1. Fine-tune the product backlog with stakeholders

The product backlog is one of the essential artifacts in Scrum. It documents the product vision shared by project stakeholders.

We always start our work on the project by filling in the product backlog with everyone relevant to the project. As soon as we’ve gathered project requirements, we can define the essential business needs of our client.

Involving stakeholders in this process is essential. During product backlog negotiations, that team learns more about the stakeholder. That knowledge allows team members to understand the results mutually and mutually share a vision.

2. Speaking of stakeholders – invite them to Scrum meetings

There’s no reason to involve everyone relevant in all Scrum meetings. But it’s an excellent idea to invite them to some of those meetings. We do that to allow stakeholders to see how the meetings are held and understand the internal team dynamics.

By knowing what sprint planning looks like or how the results of a sprint are discussed, the stakeholder gains a better understanding of how the team works. As a result, they can deliver more specific and valuable feedback to the team – and that helps all the parties involved!

3. Invest time in team building - it’s worth it

We all know that team-building activities are essential outside of agile development. But they become crucial when you need to assemble a team for a new project from scratch. We involve them in informal team-building meetings like dinners or company trips to ensure that our dedicated teams are ready to work together.

But we also promote teamwork through professional activities like collaborating on our open-source projects, giving weekly internal presentations, and reviewing conference talks of team members.

We believe this investment offers excellent ROI in the high enthusiasm and motivation of individual team members who make up our outstanding teams.

4. Set communication standards - especially for remote teams

Communication is challenging; there’s no doubt about that. And remote communication is even more complex during agile development, even if teams meet every day for daily standup meetings. It’s easy to miss critical details on Slack or during a Skype conference call.

Define communication guidelines and write them in a document distributed among all team members. For example, we made it obligatory for team members to notify everyone when they identified a new blocker, which brought us great benefits.

5. Prioritize tasks in the product backlog - here’s how

We’ve used various backlog prioritization techniques to find what works for us. Some teams are successful with HiPPO (Highest-paid person’s opinion). We don’t use this method because it doesn’t provide transparency for team members and may prevent us from making smart, data-driven decisions.

Here are some standard prioritization techniques:

MoSCoW – that acronym for Must haves, Should haves, Could haves, Won’t haves. Teams use these four primary categories to break down stories by priority. It’s the most popular and straightforward approach to prioritization. Be careful, though – it doesn’t consider the specifics of the product.

Kano model – based on customer preferences and perfect for highly-competitive markets, this model operates on five categories from the most to the least prioritized ones:

• must-be,
• one-dimensional quality (users are satisfied if a feature is present and are dissatisfied if not),
• attractive quality (users are happy if the feature is present but won’t be disappointed if not),
• indifferent quality (users don’t consider a feature good or bad),
• reverse quality (users are outright dissatisfied with a feature)

Business value – when following this approach, teams give power to a stakeholder or a product owner in estimating which user stories will bring the most financial value. This approach works for teams working on a validated business idea. This method aligns with our goal of creating software that delivers tangible and measurable business value.

Validated learning – features characterized by the highest market risk are released first to get user feedback as early as possible. A good approach for market disruptors.

Walking skeleton – priority features are enough for the product to be launched. The most common use case is the Minimum Viable Product (MVP).

Check also: How to build an MVP that does its job if you’re a non-tech founder

6. Plan new sprints when there are enough items in the product backlog

It only makes sense to plan a new sprint when your product backlog has enough tasks to fill out at least two sprints. Otherwise, you risk that your project suffers from scope creep. This happens when your project scope grows without control because you failed to fully define the scope of the upcoming sprints in the backlog.

Keeping a close eye on burndown charts also helps avoid that problem. A burndown chart displays the amount of work the team completes in a sprint and the total work remaining. You can use such charts to predict your team's likelihood of completing work on time. We also use them to inform the team of any scope creep that may occur during the project.

7. Capture bottlenecks by visualizing dependencies

This technique always helps us to manage bottlenecks and reduce their impact on our work. We start by dividing all dependencies into two groups: functional and technical dependencies. We ask all relevant people and product owners to define functional dependencies and engineers to identify the technical ones.

Here’s an example of a functional dependency:

We can’t design a landing page before completing the shipping set-up workflow.

A technical dependency could look like that:

We can’t develop a shipping set-up workflow before integrating a payment gateway beforehand.

Once you map all dependencies, you’ll be able to identify bottlenecks. Then you can reconsider their structure or de-prioritize some of them.

Agile software development best practices - the checklist

1. Fine-tune, the product backlog with stakeholders
2. Speaking of stakeholders
3. Invest time in team building
4. Set communication standards
5. Prioritize tasks in the product backlog
6. Plan new sprints when there are enough items in the product backlog
7. Capture bottlenecks by visualizing dependencies

The takeaway

At Sunscrapers, we’ve always believed in the power of teams. While project leads or product owners take it upon themselves to prioritize work, it’s teams that decide how to do it and self-organize around granular tasks.

For a custom software development company like ours, Agile is critical because it helps us to empower teams and maintain control over project deliverables that help our clients succeed.

Contact us

Get in touch with us if you need help choosing a suitable working model for your business. We help companies from different industries meet their technology needs with careful planning and choosing the most appropriate working models.

Reach out to us at hello@sunscrapers.com

Read more

1. Best timing for Scrum Ceremonies during Agile sprints
2. 6 proven practices for scaling agile development teams
3. Outsourcing best practices: How to manage agile collaborations with challenging clients

Articles mentioned in the post:

1. The Agile Manifesto
2. Python best practices: How to contribute to Python open-source projects
3. How To Build An Mvp For A Non-Tech Founder
4. How to choose the right custom software development company