Posts Tagged ‘Agile’

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.

Ownership

The product development lifecycle is complex, but in order for it to run like a well oiled machine there needs to be solid product ownership at the heart.

The below video explains Agile Product Ownership incredibly well and covers:

A typical Product Owner R&R would also be:

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Epic breakdown to user stories
  • Requirement workshops and documenting them
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

More info here on how to scale product when the time is right.

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, Product Executive or Business Analyst.

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.

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.

Once you’ve created a solid Product Vision, it’s likely you’ll be asked to provide more granular details on the ‘what’ and ‘when’ and the Product Roadmap is a great way of helping you answer that.

The product roadmap is also a good way of giving the development teams an idea of the exciting upcoming features / problems to solve for the product.

Key points of a Product Roadmap:

  • It should be at a high level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the product backlog items (PBI)
  • It needs to include dates spanning the next twelve months whether monthly or quarterly
  • The bars on the chart show when items start and when the development will be complete (live hidden)
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus / delivery and that things can and will likely change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve month view rather than knowing whether something starting in six months time will be delivered exactly a month later than that for example
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important thing about the Product Roadmap is to always provide a sign of intent for when product items will be delivered over the next twelve months, with the key word being ‘intent’ here ie. Not exact drop dead delivery date and a couple of people with experience of productivity could use gut feel which is totally acceptable, rather than dragging developers away for days on end to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.

A sign of intent for the next twelve months for the product is also better than a half empty roadmap!

Vision

It’s worth spending time coming up with a compelling vision statement, because it’s something which will be repeated over and over again as it’s the key driver to drum up excitement, passion, investment, confidence and trust that the product end goal is rather spectacular, solving the big problems and then in turn delivering huge value for the business and customers.

First things first, craft your vision statement which should only be one clear sentence, where in a nutshell it should explain what you’re looking to deliver, to who and why giving off a wow factor:

Vision statement

Then create a product vision board specifying who the target market is for your product, problems the product solves, clarifying what the product is and how the product is going to benefit the business and customers:

Vision board

Lastly, having a vision diagram is a great way of providing stakeholders and the business with a snapshot using one image of where you’re at with the product and where you’re heading. Having colour coding for ‘live’, ‘in progress’, ‘planned’ and ‘to do’ would cover it – there are plenty of mind map tools to help you visualise your product, one of which is Lucidchart which comes as a plugin for Confluence also. It’s important to keep the product diagram focused on high level features rather than detailed technical solutions around systems as that would be more of a technical architectural diagram:

Vision diagram

Having a solid product vision isn’t just to help the business allocate resource, but it’s also essential for the developers to know exactly where they need to head and why.