You know how it goes. Stakeholders start to use the work you’ve produced and then start to highlight that it doesn’t work the way they want. The Project Manager highlights this is what the business signed off on. The developers and testers claim its not broken, it’s that way by design. Is it really a bug? Do you need to start following a formal ITIL Problem Management processes?
Incident and Problem Management is a big part of ITIL. It’s highly useful in helping people – from stakeholders to team members – understand what a bug really is and what it is not.
A typical Definition of Done for an agile software team includes ensuring there are no Severity 1 or 2 defects for the items in the Sprint. Some teams will even go so far as to address any and all Severity 1-2 defects they find, regardless of whether they’re related to the PBIs in the Sprint or not.
When everything is broken, it’s typically all hands on deck to fix the issue.
If defect is part of a Product Backlog item in the current Sprint, the team resolves it this Sprint. If defect is part of a Product Backlog item from a previous Sprint, though, the team typically does the following:
If defect can’t be associated with a Product Backlog item:
The Product Owner might, though, negotiate some scope out of the current Sprint in order to address the problem immediately.
Minor and cosmetic defects always find their way to the Product Backlog so the Product Owner can determine the best time to address the issue. Sometimes typos and grammar issues are a potential reputational risk, so they often end up finding their way into the very next Sprint.
With a clear definition of a defect it’s easy for a Product Owner and their team to explain how they will address quality issues in their work. It’s much easier then when someone claims that something is broken what the definition of “broken” means for your team.
If a stakeholder complains that a feature doesn’t work the way they want it’s not unrealistic to spend time with them to find out the behaviour they do want. Using Acceptance Criteria helps to step out what is expected. Spend Backlog Refinement time understanding what the intended behaviour is and write it in a new Product Backlog item for a future Sprint. The stakeholder should engage with the Product Owner to influence the timing of the new work.
When you get to the Sprint Review, walk the stakeholder through the acceptance criteria and demonstrate that the functionality meets the acceptance criteria. If it’s still not the way the stakeholder wants it to work, help the Product Owner to work with the stakeholder to understand and document the new behaviour. Importantly, explain that it’s not a defect – it’s just a change that will go into the Product Backlog.
Stakeholders often get frustrated when things don’t work the way they want. Many don’t understand agile practices, defect definitions, or the way complex products are put together. It’s a Scrum Master’s job to help stakeholders work effectively with an agile team. Being open and transparent and inviting stakeholders to Sprint Review can go along way to improving transparency and trust and reducing the likelihood of angry people complaining about the changes they need to their products.
How do you write great User Stories?
Understanding the value stream’s attributes and how the enterprise serves its customers, allows us to look at ways to optimise the operational value stream. This is why measuring flow metrics such as Ability to Innovate and Time to Market based on mapping the value stream are key.
What are flow and value metrics and why should you make the change from project management metrics ?
When building Agile OKRs I start with the strategy and then ask if the attribute we are measuring, increased or decreased, and by what percentage? Thi
Facilitators can use many techniques, but this does guarantee that the outcome will be reached. Ultimately linking the facilitation pattern to the objective of the interaction, makes the event more effective and helps contribute to team success in achieving their goals.
An effective Product Owner is a strategic agile product manager that ties the Product Vision into the daily work by having a product management entrepreneurial mindset.
Copyright © Zen Ex Machina® and ™ (2021). All rights reserved. ABN 93 153 194 220