People can get very philosophical when talking about agile development. And often, a product manager’s discussion of their company’s agile philosophy is so abstract and high level that you’re left wondering: What exactly does this organization’s agile development process actually look like?

So, let’s talk nuts and bolts.

Let’s assume you’re a product manager and you want to use agile to improve your team’s process, speed up your development cycles, and deliver better products. There are plenty of agile experts whose work you can consult to help get you started. We’ve written pretty extensively ourselves about how to use agile development to improve your product roadmapping.

But for this post, we’ll discuss a handful of agile best practices we think are essential to the process—and which we’ve seen many product teams neglect.

1. Establish a product owner for the agile team—and make sure they fully understand their role.

Every agile development team needs a product owner. In most cases, this will be a product manager. And this isn’t merely a vanity title. Being a product owner has real meaning, which you should understand if you want your agile process to work.

Your responsibilities as product owner include:

  • Determining who will be on your product team, and shielding the team from external interference. (More on this below.)
  • Setting the vision for your product team, so they understand what’s expected of them.
  • Keeping your team’s focus tight—which usually means a focus on the next two or three sprints, and only on the epics and stories needed for those sprints.
  • Making yourself available at all times for your product team during the sprint, in case they have questions or need guidance. If you can’t be available for the duration of a sprint, then you can’t be the product owner—you’ll need to transfer that responsibility temporarily to someone else.

2. Establish the rest of your agile team—keeping out all but those integral to your development plan—and determine and assign their respective roles and responsibilities.

One misstep a lot of product managers make in building their agile teams is in allowing the wrong people to join, and neglecting to include some of the right people.

Many product teams, for example, forget to include QA resources. This can lead to bugs making it into the demo—and, ultimately, to rework, which should happen as little as possible in an agile environment. The agile process itself is designed to avoid such backtracking and needless extra work.

Many product owners also mistakenly include too many people on the team, or at least in the product demo at the end of a sprint. Shouldn’t we invite someone from sales, they reason, or marketing?

But during a sprint, your product team needs to be focused on building—not on fielding a request for new features from sales or answering a marketing rep’s question about why certain epics have been prioritized over others on your product roadmap. There are places for such conversations—but a product team’s sprint isn’t among them.

To build your process on agile best practices, your team should include:

  • A product owner (whose primary responsibilities I’ve outlined above and will have more to say about below)
  • A scrum master (whose role it will be to translate the epics, stories, and other items on your sprint list into actionable tasks for her developers—and to ensure that dev team is fully deployed at all times, with no wasted resources)
  • Your QA resources (who will be responsible for testing the items in development before they’re presented to the product owner in the sprint demo)

3. Translate the strategic elements of your roadmap into your sprint list—and review those details with your team to ensure clarity before the sprint begins.

Product managers often ask whether or not they should share their year-long product roadmap with their development team. If the team is going to be focused on short-term sprints, they wonder, should I risk confusing them with a longer-term strategic vision and details they won’t be working on for many months?

Tweet This:
“Translate the strategic elements of your roadmap into your sprint list—and review those details with your team to ensure clarity before the sprint begins.”

Generally speaking, yes, a product manager should share her product roadmap with development—provided that roadmap is built at the strategic level, is easy to view, and isn’t merely a long list of features and to-do items.

But in an agile framework, the product manager (or product owner) should present this roadmap only as a way of strategically orienting her product team to how the stories and features they’ll be working on roll up to a larger, more strategic plan for the product.

Then the product owner should shift focus from the strategic to the tactical—and review with her team the epics, stories, and other items they will be working on for the next sprint (maybe two), so they are able to keep their focus tight and on-mission.

This means that by the time you’re done with your sprint kickoff meeting, your scrum master and development team should understand exactly what you need from each story listed on the upcoming sprint. Which leads to the next agile best practice…

4. Clear as many distractions as possible for your team as soon as your sprint begins.

During your sprint—which in most cases will be about two weeks—your development team (including your QA team) should be focused exclusively on the sprint items their scrum master has assigned to them.

In other words, among your roles as product owner will be to build a wall around your product team during every sprint—allowing them to work on those sprint items free from outside distractions.

Which is why it’s so important that you ensure your product team is clear on what you’re expecting from every story, every feature, etc., before the sprint begins. One of those distractions could be that they realize mid-sprint they don’t know what you meant with a certain story—and they have to ask you for guidance at that point.

Remember, once your team starts a sprint, that’s it. If you’ve done your job as product owner, you’ve made sure they know exactly what they need to do, and you’ve also allowed them as much of a development cocoon as is feasible (you can’t prevent all outside distractions)—so they can deliver their best work before the sprint ends.

5. Don’t forget the retrospective!

Here’s another common mistake in agile shops. Even the most well-intentioned product managers skip the all-important “retrospective” at the end of a sprint because they believe they’re just too busy to have that meeting, or because they simply forget to call it.

The whole point of agile development is that you and your team are constantly learning from your processes, analyzing what’s working and what isn’t, and adjusting those processes to make them better next time.

Tweet This:
“The point of agile is to constantly learn from your processes, analyze what’s working and what isn’t, and adjust those processes to make them better next time.”

That’s why the agile retrospective meeting is designed to be so short—maybe just 20 minutes. No matter how quickly things are moving in your organization, you’ve got 20 minutes, don’t you?

Take that time, with your team, to review your last sprint. Talk about what worked, where your process might have fallen short a bit, or even where it completely fell apart. Then discuss how you can apply what you’ve just learned to improve your development process for the next sprint.

Because there’s always a next sprint.


Have more best practices for agile teams? Share them in the comments below.

Post Comments

2 Comments

  • Trish
    January 11, 2019 at 2:40 am

    There is no such thing as “best practices” in agile or any frameworks.
    There are agile principles and in scrum a guide.
    no where are best practices defined as these restrict a team in self organizing.
    We can share leading practices across products but one size does not fit all in agile.

  • John
    January 16, 2019 at 6:59 pm

    I have to agree with the comment above, except I think there are some exceptions where this information is helpful. A seasoned agile team should stick with the retro process to optimize their practices by applying agile principles based on the teams experience. However a completely green Agile team, or a team that is having difficulty finding its “groove”, may benefit from ideas like these as a solid point to start from.

    I also think point 5 should stand no matter what. My experience was that in the beginning we had lots of ideas and actions from the retro, but after time they grew less as we made the changes. It may seem as though the retro process is no longer adding value, but I believe it should never be entirely abandoned. We have at times had very short retros when all team members agreed they had nothing to put forward, but agreed as a team we would never skip it. We have also had issues where the team was powerless to fix, so we side-bar those issues and only check them irregularly to see if the situation has changed.

Leave a Comment

Your email address will not be published.