Certified Scrum Product Owner (CSPO) training is a course which focuses on improving and consolidating understanding of key agile concepts. It includes practical workshops, informal discussions between Product Owners from a range of industries, and sharing tactics for overcoming common problems with Scrum.
Our very own Product Owner, Peter, recently attended a CSPO course and has kindly shared his feedback. But first…
What is Scrum?
If you’re not familiar with Scrum, it is a framework that encourages teams to work in a customer-centric manner. With the focus being on delivering customer needs and business value rather than simply delivering features. It is a flexible process which enables continuous improvement through iteration.
Work is completed in sprint cycles which last for a set period of time e.g. 2 weeks. The team has a backlog of issues they would like to work on, which is continuously updated. Each issue has an importance weighting and a set of action criteria (ACs) which outline the specific work required for an issue to be considered resolved.
Before a sprint cycle begins, there is a planning meeting where selected issues are presented and discussed. The team estimates how long they expect each issue will take to complete and then vote to select a number of issues which create enough work to last the duration of the sprint. Once the cycle ends, there is a review meeting where all work produced is demonstrated and the team discusses how the Scrum process could be further improved next time.
Scrum is generally associated with software development, and Bytemark’s engineering team have been using the method since back in September 2017. But earlier this year, we also trialled components of Scrum in our marketing team and saw great results! So you can definitely use the framework across different areas.
What is a Product Owner?
The Product Owner plays a vital part in the Scrum process. They are the individual responsible for maximising the value of our products. Therefore their role involves planning future product strategy, prioritising tasks to be completed, ensuring all team members understand each task and the value gained by completing it.
4 Key Learning Outcomes
One of the main messages Peter reported back after the CSPO training is that a central part of Scrum is to identify weaknesses, experiment and iterate towards a better process, just like we do with our products. From this, he suggested four actionable changes that Bytemark can make to their Scrum process. Any team using the framework could benefit from these points, so take a look:
1) The Product Owner should lead the review meeting to solicit feedback from stakeholders
Particularly in development teams, the work presented in a review meeting can be highly technical. This has previously led to the main contributor for each issue outlining the problem/goal addressed and demonstrating the work carried out to get there. However, this can sometimes bypass sharing information about why certain work was prioritised and details on what we hoped to achieve.
In the future, Peter will be introducing each issue and expert team members will then give the demo. We hope that sharing more about the ‘why?’ for each issue will encourage more feedback which can be used to improve future sprints.
2) The development team should own and develop the backlog
As a company, we believe in cross-team discussion and collaboration. So in the past, we have allowed any member of staff to add issues to a specific team’s sprint backlog to help generate new ideas. The problem with this is that although the ideas are valuable, they do not always fit into the current product roadmap and vision.
So, going forward, we will still take suggestions from across the company but only sprint team members can add directly to the backlog. This will ensure the all issues always move the team in the direction they are aiming for.
3) To be considered ‘done’, an issue should be ready-to-deploy
We have always considered an issue completed once all of the ACs had been done. But this hasn’t typically included test coverage, documentation, change notes etc. So this work has often had to be completed outside of the defined sprint cycle.
To improve this, we will be reevaluating our definition of ‘done’ to include these steps. This will involve increasing our estimation times and accepting fewer issues into each sprint. If an issue does not reach our agreed ‘definition of done’, it will be rejected. Additional time will be allocated in the next sprint.
4) There should be an ambitious 3 – 5 year vision
Before each sprint, we have tried to set a theme which encompasses the main goal i.e. quality of life improvements or branding work. Whilst this provided somewhat of a vision for that sprint, it hasn’t ensured that each sprint is 100% pushing us towards where we want our products to be long-term.
Peter will be working with internal stakeholders, customers and innovators to set our 3 – 5 year vision and product roadmap. He will then communicate this to all team members to aid the direction of future sprints.
Overall, the CSPO training was useful in identifying where we were already doing well. It also uncovered key improvements that can be applied across the company. Do you use Scrum in your teams? We’d love to hear more about what methods you’ve employed to overcome problems and continue improving.