Robbin Schuurman — December 8, 2017 — December 8, 2017
geralt / Pixabay
The Scrum Framework
The Scrum Framework is a lightweight framework that defines three Roles, three Artifacts and five Events, which is used to develop and maintain complex Products in complex environments. Scrum doesn’t prescribe a lot of things you must do, the Scrum Framework doesn’t include extensive practices, documents or meetings that you must follow. There are a few rules however, which are described in the Scrum Guide. Don’t try to change the Scrum Framework, don’t leave elements out before you’ve applied the Scrum Framework as it is described in the Scrum Guide!
In this post, we’ll cover 10 tips about the Scrum Framework. In the blogs to follow, we’ll also cover tips on the other aspects of Product Ownership. I hope you enjoy them!
10 Tips for Product Owners on the Scrum Framework:
1. Use a Sprint Goal
As a Product Owner, your main responsibility is to maximize the value of the Product(s) you deliver to customers and users. In order to maximize the value, you will have to make some tough choices on what to build and what not to build. You’re also making choices on that to build when. You’re ordening the Product Backlog, to maximize value, to take opportunities, to minimize risks and also to create focus for the Scrum Team! Focus is one of the core values of Scrum and it’s a very important one in my opinion. Having focus in the Scrum Team helps you to increase output and value delivery, but it also makes the team more effective, more efficient and allows for more self-organization! As a Product Owner, you can have a major impact on the success of a Sprint, by increasing focus for the Scrum Team. One way of creating more focus, is by providing the team with a guiding Sprint Goal. The Sprint Goal provides the team purpose, a common direction and clarity on then the Sprint is successful or not. Many Product Owners in daily practice don’t use a Sprint Goal, that’s such a shame!
2. Be part of the Scrum Team
The Scrum Team consists of a Product Owner, Scrum Master and Development Team. In many Scrum Teams, we find that the Product Owner isn’t acting as a real Scrum Team member. He/she isn’t available during the Sprint, isn’t engaged with the Scrum Team, isn’t supporting the Scrum Team in continuous improvement, etc. etc. As a Product Owner, you should be part of the Scrum Team, because they’re helping you in maximizing the value of the Product. If you help out the Scrum Team, they will be better in helping you out!
3. Facilitate focus for the Scrum Team
As mentioned in tip 1, creating focus for the Scrum Team is very valuable. Besides creating a Sprint Goal with the team, you could also create more focus in the Sprint by selecting Product Backlog Items that are related. For example, orden the Product Backlog by grouping Product Backlog Items that require work on the same part of a system or on the same process.
4. Don’t ‘manage’ the Daily Scrum
The Daily Scrum is an Event for the Development Team to inspect the progress made and adapt their plan for the next 24 hours. It’s helpful (but not required) that the Product Owner and Scrum Master are present during the Daily Scrum, to answer questions of the team and provide guidance or help if needed or asked. However, in practice we meet a lot of Product Owners and Scrum Masters who are ‘managing’ the Daily Scrum. They are dividing tasks among team members, they are asking what people did the last day and what they’re going to do, they update the Sprint Backlog, etc. etc. From now on, don’t do this anymore! The Daily Scrum is an Event from and for the Development Team, it’s not a status update meeting from the Development Team to the Product Owner or Scrum Master! When you stop managing the Daily Scrum, you’ll see that the Development Team becomes more self-organizing, which creates more time and space for you as a Product Owner to focus on your stakeholders and the long(er) term roadmap for example.
5. Inspect and adapt the time spend on Product Backlog Refinement
Product Backlog Refinement helps you to order and reorder your Product Backlog, it also helps you in splitting Product Backlog Items, making Product Backlog Items more clear, etc. etc. The guideline for Refinement is to spend about 10% of the Development Teams’ capacity on Refinement, but this is just a guideline! So you have to inspect and adapt how much time you’re spending on Refinement. In our experience, it helps to implement a rhythm or cadence in doing Refinement. For example, I often implement a Refinement meeting with the Scrum Team (and stakeholders when needed) two times a week, on Tuesday and Thursday for example, for one to two hours. This rhythm reduces complexity and increases predictability for the Scrum Team and it’s stakeholders. Besides implementing a rhythm, go out there and find out how much time you should spend on Refinement! For some teams it’s 5%, others 10% and again others 20%, so find out how much you need! A guideline is that you’ll want to have a Product Backlog with ‘Ready’ Items for the next two to three Sprints.
6. Deliver something ‘Done’ at the end of the Sprint
We meet many Scrum Teams who are taking up way too much work in a Sprint, often resulting in the team not delivering anything ‘Done’ at the end of the Sprint. Surely they’ve done a lot of work, surely they started working on a lot of the Items, but at the end of the Sprint, all the work (or part of it) is moved to the next Sprint. Is this something you recognize? Then this tip is for you! An important step you should take is reduce the number of Items the team takes into the Sprint! Since you want to maximize the value for the Product, your goal is not to produce as much output as possible, but to create as much outcome as possible, right? So, the team may deliver a lot of output, for example 20 PBI’s that are 80% ‘Done’, that sounds awesome! Errr.. No! Because this is twenty times zero value! If it isn’t ‘Done’, then no value for customers and users was delivered! So I would rather have ten Items that are 100% Done, because this is ten Items of value, instead of zero value.
7. Respect the Definition of Done
Under internal or external pressures (like deadlines, marketing events or other opportunities) many Product Owners start to push the Development Team to deliver faster. They are however not reducing the scope to be delivered, they are often pushing the team to deliver the same scope (or more) in less time. This often (if not always) results in major losses of Quality. When the Scrum Team is not conforming to the Definition of Done anymore, they’re delivering bad quality. On the short term, this often seems fine, but on the long(er) term, you’re creating a lot of undone work and technical debt. In many organizations, we’ve seen (about 4 to 6 out of 10) teams that were solely working on issue solving, bug fixing, problem management and resolving technical debt. It’s always much more costly to fix quality after going live, than to build in quality upfront! So respect the Definition of Done and let the Development Team deliver quality products!
8. Don’t mistake the Sprint Review for ‘a demo’
In many organizations, the Sprint Review is treated like a ‘demo’. Although ‘demoing’ the Product Increment is part of the Sprint Review, it is not it’s sole purpose! The goal of the Sprint Review is to collaborate with stakeholders in order to gain feedback on the Product Increment, to inspect the market, to inspect the Product Roadmap and to collaborate on the next steps to be taken in order to maximize value for the Product. This all means that the Sprint Review is a collaborative working session. It’s not a status update (using Powerpoint) from the Development Team to the stakeholders, or worse, from the Development Team to the Product Owner! It’s a meeting which helps the Scrum Team to inform the stakeholders, to interact with them, to exchange ideas and feedback and to decide on the next steps to be taken for the Product.
9. Work with the Scrum Master on a daily basis
As a Product Owner, the Scrum Master (or Agile Coach) is your friend! He or she can help you, coach you, advise you, train and mentor you with all kinds of challenges. I meet a lot of Product Owners however, who are rarely collaborating with their Scrum Master. This is such a pity! The Scrum Master can help you in coaching stakeholders, facilitating stakeholder Events, coaching you in improving your Product Backlog management skills, stakeholder management, etc. etc. The Scrum Master isn’t just there for the Development Team, the Scrum Master is also there for you and the organization! So collaborate in order to deliver more value!
10. Be involved in and committed to continuous improvement
In many Scrum Teams, Product Owners are disconnected/unavailable during the Sprint or they are not involved in continuous improvement. We’ve encountered many Scrum Teams in which the Sprint Retrospective was an Event performed by the Scrum Master and Development Team and where the Product Owner was never there, or was there once every few Sprints. This is a big misunderstanding of the Sprint Retrospective and it’s such a loss for the Scrum Team! As a Product Owner, you should definitely be participating during the Sprint Retrospective! As a member of the Scrum Team, the Product Owner should be involved in continuous improvement too. There may be things you can do better as a Product Owner, there may be improvements to be made in the collaboration between you and the Development Team, there may be some important decisions to be made, so you should be there. Besides that, you want to maximize value right? If the Scrum Team can make improvements happen in the process, collaboration, communication, etc. etc., then you should want to know! Because if the team becomes more effective, you could deliver more value for customers and users!
So, these are the 10 tips for Product Owners on the topic of the Scrum Framework! I hope you enjoyed them and that they’ll help you in becoming a better Product Owner!
Business & Finance Articles on Business 2 Community
(71)
