Posts Tagged ‘Scrum’

CSPO

Whether you’re a product led organisation or keen to take product ownership to the next level, a good way to ensure that Product Owners are well equiped to effectively handle their product in an agile environment is through various Product Owner Certifications.

The first level of certification is becoming a Certified Scrum Product Owner, where the course is typically over a two day period with modules including:

  • Introductions to Agile and Scrum
  • Agile Basics
  • Scrum Basics
  • Roles and responsibilities
  • Team Chartering (Ready, ‘Done’ and Team agreements)
  • Product Visions
  • Product Roadmaps
  • User Stories
  • The Product Backlog and Product Backlog Refinement
  • Agile Estimating and Planning
  • Sprints
  • Participant-Driven Q&A

Acspo

Once you’ve become a Certified Scrum Product Owner and you want to take product ownership to the next level then attend the Advanced Certified Scrum Product Owner® course which includes:

  • Product Backlog Prioritisation & Refinement
  • User Stories
  • Rapid Vision Generation
  • Roadmapping That Works
  • Value Proposition Design
  • Hypothesis Testing
  • Use Cases
  • Getting to Done
  • In-person Collaboration
  • On-line Collaboration with Weave
  • Understanding Yourself as a Product Owner
  • Lift-off for Agile Teams
  • Scaling Scrum and other Agile processes
  • Extreme Programming
  • Facilitative Listening I & II
  • Inclusive Solutions

Csppo

The final step is becoming a Certified Scrum Professional Product Owner. Certified Scrum Professionals challenge their teams to improve the way Scrum and other Agile techniques are applied. They have demonstrated experience, documented training, and proven knowledge in the art of Scrum.

Are you ready for the next level of experience and expertise in the art of Scrum? If so, it’s time to elevate your career further by earning the CSP®credential.

Scale

Once a product is mature and the product roadmap is filled up with valuable product iterations, it’s likely that the product owner and senior management will be keen to find out how some of the financial value driving product iterations can be delivered sooner.

Whilst having to balance technology improvements, technical debt, regulatory, security, bugs, dev ops and business requirements with only having one development team on the product stream would make this difficult, as there’s little room to work on multiple different types of work concurrently eg. business requirements concurrently with the more technical driven requirements.

To work on different sets of requirements concurrently, the product would need to scale which would involve adding additional product development teams to the product line. With more development teams working on the product would also require additional firepower from the technical architect and product owner role if delivery is to remain efficient and ROI positive.

An example of how you can scale the product owner role across multiple development teams who are working on the same product line:

Chief Product Owner (CPO)

  • Responsible for ensuring that the Product Owners are handling their product lines effectively
  • Handling the high level product strategy across all product lines

Product Owner (PO) / Senior Product Owner (SPO) of the Product Line

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Backlog grooming
  • Sprint planning

Product Owner of the Development Teams (Associate Product Owner (APO))

  • Customer analysis
  • Epic breakdown
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

The Associate Product Owner of the development teams could also be referred to as Feature Product Owner, Junior Product Owner or Product Executive.

In order for the Product Owner to be able to focus on the product vision, prioritisation of the product backlog and product strategy to ensure the product remains competitive, it’s important that when adding additional development teams to the product that they get additional product owner support to help them out with the more tactical day to day activities, as you can see from the split in tasks above – Product Line Owner handling more strategic tasks especially prioritisation in all instances and the Associate Product Owner handles more tactical tasks.

Spreading a product owner too thin with little support could result in a lack of focus on both product strategy and getting product backlog items delivered in an efficient way.

Ops

All products will have an element of BAU (business as usual) and strategic work, where both are equally important to get after if the product is to remain competitive now and in years to come.

BAU work can also be referred to as ops (operational) work and I’ve always preferred the word ‘Ops’ over ‘BAU’ because no problem to solve should be looked at as solving it in the usual way which BAU can often be treated like. Also there’s often a stigma attached to BAU irrelevant of the business value it drives which is bonkers, so let’s look at the definitions of both:

  • BAU – work which doesn’t involve significant architecture redesign or thought, but BAU work is typically the blood line of the business
  • Strategic – work which involves a significant amount of up front technical design and often uses the latest / next generation technology. Strategic work often comes into play if there’s an architectural org restructure, the existing technical platform is no longer fit for purpose or it’s a new product

When it comes to delivering either BAU or Strategic work, there’s a couple of ways:

  1. Simply follow the same agile process which any other problem does, which includes adding a high level PBI (Product Backlog Item) detailing the problem to solve with value and then the Scrum Master / Team Lead looks well ahead in the product backlog to start contemplating approaching the ‘how’ with very close collaboration with the Technical Architect (TA) with the aim to get the item in a ‘Ready‘ state for development. This would in turn lead to the development teams planning in Technical Support backlog items to help the TA with technical designs, spikes or investigations well in advance of the problem appearing towards the top of the backlog which applies to both Scrum and Kanban.
  2. Split development resource into BAU only and Strategic only

The risk with No 1 is that the Scrum Master doesn’t collaborate with the Technical Architect soon enough resulting in the PBI hitting the top of the backlog before technical designs have started, causing significant delays to getting after the strategic work.

But there’s a much bigger risk to No 2 where there would naturally be a big reluctance for a team to work purely on BAU and therefore miss out on any green field project and there’s risk of breaking the ‘One Team’ mentality across the product development teams working on the whole product together and in turn impacting team morale.

With facilitating processes and tasks at the heart of the Scrum Master role, it requires someone with a proactive, helpful, motivated, can do, kind, organised and supportive mindset in order for requirements to be solved in an efficient way in the right priority order.

With the Product Owner, Developers, QAs, Technical Architect and Stakeholders all focused on getting their job done where there are clear boundaries, it needs someone to fill any missing gaps or connect them together in order to get the job done, which is where the Scrum Master comes in.

Let’s look at a day in the life of a Scrum Master:

Scrum master

Done

Once the product backlog is in a good quality condition and the product backlog items (PBIs) start moving into development, there’s a significant amount of tasks to tick off before the feature can be marked as ‘done’.

Typically a development team would use a ‘definition of done’ (DoD) as a reference to ensure that none of the processes get missed off before it’s ‘done’, as each of those processes are essential and could have considerable consequences for the business and customers if it’s not done.

Some examples of what could be in a definition of done:

  • Code is reviewed by someone who didn’t do the PBI
  • Code is deployed to test environment
  • Feature is tested against acceptance criteria
  • Feature passes regression testing
  • Feature passes smoke test
  • Feature is documented
  • Feature approved by UX designer / stakeholder
  • Feature approved by Product Owner

Missing any of the DoD processes before a feature gets delivered to a customer could result in critical bugs across the feature, causing bugs across other features in the code, bring down the product or delivering the wrong requirement, so it’s essential to take the definition of done seriously even if it means taking the PBI over to the next sprint resulting in potentially not meeting a sprint goal.

Invest

In order to avoid lots of panic and chaos the day before sprint planning because there’s no work in a ‘ready‘ state, it’s essential to have regular backlog grooming sessions which would result in having at least six weeks’ worth of high priority ‘ready’ work in the product backlog.

To get PBI’s (Product Backlog Items) in a ready state, it can take a lot of effort especially when it comes to chasing down dependencies or getting answers around the business requirements, but this is where the Scrum Master comes in to help out – although the Product Owner owns the product backlog, it’s the responsibility of the Scrum Master to help, guide and support the team to ensure they’re having frequent effective backlog grooming sessions, so there’s a good few weeks worth of ready PBI’s.

A new PBI is the start of a conversation and shouldn’t include solutions, so there should be ongoing questions around the requirements well in advance of the work going into development, until the development team feel they have enough information to size the PBI and then mark it as ready if there’s no dependencies.

It’s important to have a good quality product backlog (high priority items in a ready state) and frequently groom PBIs, to ensure the development teams are not only working on the highest priority items, but also that they’re working in an efficient way.

Some tips to getting a good quality product backlog:

  1. Create the user stories and prioritise in the backlog sooner rather than later – as a minimum the story needs to include ‘as a’, ‘I want’, ‘so that’ language with some high level acceptance criteria which will help start the conversation with the developers, giving them weeks to ask questions up front before it appears towards the top of the backlog.
  2. Making the problem / requirements clear with a stakeholder point of contact within the story for reference
  3. Having a clear title (summary) to the story, so you don’t have to open it up to find out what it’s about
  4. When there are questions from the developers to answer either by the Sub Product Owner (or Product Owner), stakeholders or technical, try to avoid leaving these unanswered for days – these should be responded to immediately as a priority
  5. For the ‘Feature Backlog‘ to be presented to the team monthly or bi-monthly, so they know clearly what the value of the relevant PBI’s are with some context around them
  6. Having flexible backlog grooming sessions – there’s no rule here, the teams can get together everyday if they like to groom the backlog until they’ve caught up
  7. Reinforcing to the development teams that they don’t need to know exactly what code to write and where in order to size the PBI, but instead the sizing should be based on a suitable solution making some assumptions
  8. Attaching customer flows / UX to the PBIs, with a link to ‘As Is’ and ‘To Be’ documentation

At least 10% of the teams time should be spent on grooming the product backlog and unless enough time is invested or they don’t get the support they need from the Scrum Master or Product Owner, then there’s risk of inefficiencies or the teams working on low priority PBI’s (Product Backlog Items) as the high priority items aren’t being groomed enough in time for sprint planning.

To compliment the Product Roadmap, there should be a prioritised product ‘Feature Backlog’ which gives both stakeholders and the development teams a detailed overview of the Product Roadmap items still at that high level (Epics / Product Iterations).

If you use JIRA to manage your software delivery projects and you have your product roadmap items at an Epic level, then you’re able to simply setup a Kanban board with just one column called ‘Feature Backlog’ with a filter set to show only Epics and Epics which are ‘in progress’ or ‘to do’.

To visualise the feature backlog in a better way than the Kanban board, it’s possible to also show that same JIRA epic search filter across the likes of Confluence or Aha! where you can specify what JIRA fields to show.

Depending on your custom fields in JIRA, looking at the Feature Backlog should give stakeholders and development teams working on the product a high level (iteration / epic) idea of:

  • Priority order of all epics / iterations
  • Status – what’s in progress, planned or to do
  • Business value – whether it’s driving x incremental revenue, saving x money, avoiding x fees, meeting regulatory requirements, contract deadlines, tech debt, advancing technology etc
  • Description of the iteration / problem you’re solving
  • Delivery date which should match the dates on the product roadmap
  • Size of work

The Feature Backlog is a great way of showcasing at a high level the value of the product iterations which are currently being worked on and what’s planned in the next twelve months.

The Feature Backlog also helps the development teams understand the details of what problems are upcoming to solve, so they’re able to think about how to approach each epic / product iteration well in advance.