Volkerdon - The best solution to prepare for Agile and Scrum certifications

As a Product Owner, it’s quite easy to disengage during sprint execution because it seems as if your role gets somewhat diminished. You feel like the team is rolling along with work and you are only there to help when asked a question.

From my point of view, this is another area that can be a differentiator for a great Product Owner. That being said, what does a Product Owner do during the sprint?

Sprint Engagement

First of all, you need to fully engage with the team. Attend all daily stand-ups and listen intently to what’s going on. Look for opportunities to collaborate with the team each and every day. Are there testers you can sit down with to define and/or refine acceptance tests? Are there any stories or features approaching a demonstration state? If so, sit down with those team members and give them some early feedback. How about bugs surfacing that may need your judgment and attention? The list of activities goes on.

Remember, too, that you’re a team member, so speak to your own efforts in the daily stand-up. Share your tasks, efforts, plans for that day, conversations you’ve had with stakeholders, etc.

Sitting with Your Team

I prefer it when Product Owners are co-located with their teams. There is no replacement for listening in on the activity; conversations, pairing, design debates, questions, comments, bugs, problems or impediments, and just being there engaging naturally and immediately, when and where you’re needed within the team.

However, in some cases, this is just not possible. So, the onus is on you to look for alternative strategies to support your team. Some examples include:

• If you’re out of the office, dial-into all stand-ups or relevant meetings even while you’re traveling.
• Establish a notion of office hours, where you’re available for the team; I’ve seen an hour or two in the morning and afternoon as quite effective approaches. 
• You can delegate your responsibilities, as a whole or subset, but ensure your team knows you’re doing it; the details, for how long, etc. and who is representing you and in what capacity 
• Even if you’re remote or out of the office, regularly reach out to your team and ask if you can help; let everyone know you’re available, engaged, and that you care!

I guess the point here is that being present, even when you’re not physically there, is incredibly important to you, your team and the ultimate sprint outcomes. Stay committed to engagement and your team will sense it and respond in-kind.

Testing

In many teams, the Product Owner is in a wonderful position of understanding customer needs and expectations, both at the story and goal levels. Given that, and their need to understand sprint progress, I usually find Product Owners spending considerable time testing their application.

Usually, they’re working with the test team and on test-focused environments so that the software is, more often than not, a bit more mature. At regular intervals, they’re checking on feature interaction and workflow; considering overall customer experience and usability of features being delivered within the sprint.

Time and again they’ll have questions and, as a result, the testing will drive healthy collaboration from the Product Owner towards the team. They’re also heavily collaborating with testers on the individual story acceptance test requirements and, if using ATDD oriented tools62, they’re crafting their own acceptance tests for automated execution.

The key point is that testing is a natural extension of the Product Owner role and a great way to contribute to your team’s efforts in a visible and high-impact way. I’d really encourage this to be a part of your focus within each sprint.

Impediments

As impediments emerge that relate to you, don’t wait for the Scrum Master to track you down for follow-up action. Instead, be proactive in moving all of your personal impediment actions forward. Show the team you care by the sheer level of your attention and impediment resolution focus.

Also, stay aware of sprint progress via your sprint burndown charts and other team Information Radiators63. Stay curious; ask questions of the team about work progress and challenge them if you feel work is falling behind their goal commitment. If they’re ahead of the sprint plan, certainly prepare additional work that they can pull into the sprint.

If you find that a sprint is in jeopardy and the team is falling behind, get engaged with your Scrum Master and team to figure out how you can adjust sprint contents and still meet the sprint goal. Be willing to listen to all alternatives for changing sprint scope, but still achieve your goals. Stay open-minded. In fact, proactively suggest adjustments yourself.

I call this activity making micro-adjustments to the contents of a sprint. Every adjustment should be aligned with the goal. And the adjustments happen in “both directions”, based on positive and negative discovery.

Bugs

During the course of all software development, bugs arise. It’s simply natural. In the case of Scrum and other Agile Methodologies, you want to try and resolve and/or fix all bugs as soon as they’re discovered. Your team will need your help in deciding what are valid and immediate bugs versus what can be deferred. While maintaining a “Lean – Fix it now” mindset, help lead your team forward with balanced decision-making. 

You should also be asking questions and reaffirming the quality levels of their work. I’ve seen many Product Owners that focus on delivering features, over-delivering high-quality features. You want to be a champion of the latter, and motivate the team towards this by asking quality-oriented questions. For example – “How could this set of bugs have been avoided?” or, “What can we do to improve overall product quality?” This sets the tone that you’re equally committed to quality as you are to production, which is an extremely important message for your team to continuously hear!

Adjusting the Sprint?

As the previous story indicated, sprints quite often don’t turn out as planned and something needs to be adjusted in the middle of things. One reason might be to make priority changes, based on external customer changes to the content of the sprint. Another is when the team finds itself struggling with their original commitment to the work; if they either under or overestimated things. And another reason is that software is by definition a challenging endeavour and, therefore, sometimes unexpected risks may surface. We’re going to explore a few scenarios here.

One important point is that none of these actions are solely the responsibility of the Product Owner. In fact, the leader here should be the Scrum Master. He or she is your partner and should guide you and the team in making any necessary adjustments, etc. However, you do play a significant part in what I’ll call the sprint recovery process.

Content Disconnect

The team is struggling to deliver to their sprint commitment. Within the first few days of the sprint, you and the Scrum Master realize that an adjustment is necessary. I’ve seen several approaches to this. Classically, Scrum allows for cancelling and re-planning your Sprint. That works well if you’re a stand-alone team. However, if your team is synchronized with others, then this approach can be awkward in that you’ll need to plan a reduced-length sprint in order to maintain your cross-team synchronization.

Another approach is to simply run a re-planning meeting or what I call a “soft reset”. This is where the team, given the recent discoveries, tries to maximize the delivery of content towards the original sprint goal. Since you’re using the previous sprint backlog as a baseline, this is usually a quick meeting where you and the team figure out an adjusted game plan for the sprint.

If done quickly enough, within the first 1-3 days of a two-week sprint, I’ve seen teams significantly recover their progress and often meet the original sprint goal. If detected too late, then you’re simply trying to maximize the delivery towards the goal; not meeting the goal itself.

Capacity or Focus Disconnect

Let’s face it; we live in the real world where interruptions are incredibly common and dynamic. For example, if a Severity 1 bug surfaces at a customer site, rarely is it the right answer to tell them that they’ll have to wait until the end of the sprint.

Or if you have one database architect for ten Scrum teams, rarely is it the right answer to have them focus on one team over the others. Interruptions happen and multi-tasking isn’t entirely avoidable. That being said, it can be incredibly demoralizing to a Scrum team to have their sprints derailed with interruptions.

When it happens you want to immediately discuss the impact with the team and re-plan the sprint; trying to maintain the sprint goal as much as possible. But beyond the current sprint, try to put some thought into how the team can mitigate similar situations in future sprints, for example:

• Reserving time (capacity) for external interruptions. 
• Allocating a team member to be the ‘buffer’ for external interruptions. 
• Planning on less work within the sprint; yes, that’s not a typo—I really said that. 
• Raising an impediment for specific team skills in order to effectively execute the backlog. 
• Capturing interruption time during the sprint as ‘drag’ or interrupt time to be better able to quantify the impacts.

Priority Disconnect

One of my favourite Product Owners struggled with changing his mind quite often within sprints. We were working on an eCommerce SaaS (Software as a Service) application where “things changed” often due to the customer and market dynamics. In these cases, he was more likely to cancel the sprint and then re-plan a new one based on a major priority shift in the backlog.

However, when re-planning we tried to stay open-minded about integrating the new work and maintaining some of the original sprints’ focus. This lessened the teams’ feelings of getting “jerked around”.

Another aspect of this is insufficient look-ahead. I was never convinced that he couldn’t anticipate these changes in some way. Remember, we were on a 2-week sprint model which is fairly nimble. As we’ll discuss next, looking ahead and anticipating events is another important activity during sprint execution.

Preparing for the Sprint Review

During the sprint, you should also be monitoring progress on a story-by-story basis and mapping progress to the overall burndown chart to get a feel of whether the sprint will be successful or not; in other words, preparing for the sprint review. One of the core tenants of agility is delivering and demonstrating working software which should happen in Scrum in the sprint review.

Source: 

• Galen, Robert. SCRUM Product Ownership