Product Owners and others responsible for creating and maintaining the Product Backlog often focus on functional items.

With good engagement in the Backlog Management process from the Development Team and Architects, technical and architectural items also find their way into the Product Backlog.

But what about the human-centric items related to accessibility, inclusivity, internationalization and sustainability?

Through the talk and with the help of several supporting examples and a short exercise, I would like to highlight the importance of addressing these aspects in the Product Backlog. The examples will include examples of good and bad backlog items and design decisions.

I will also share some tips on how Product Owners and supporting roles can work these aspects into the Backlog Management process. These will include some ideas from Design Thinking but will not be limited to that.

 
2 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Typical Backlog Management and Design considerations – 10 mins
  • Overview of human-centric aspects of backlog items and design with examples – 20 mins
    • (what these aspects are and why they are important)
      • Accessibility
      • Inclusivity
      • Internationalization
      • Sustainability
  • Short exercise to create backlog items covering these aspects for a sample product - 10 mins
  • What can we do to include these aspects in our Product Roadmap and Design – 10 mins
    • Backlog management approaches
    • Ideas from Design Thinking
    • Which roles can participate and help

Learning Outcome

For roles that influence the Product Backlog and Product road-maps and Design decisions, the session will broaden their view and encourage them to consider more modern and inclusive aspects. This will be established in a highly interactive way and through an exercise.

The audience will also gain some tips that they can use immediately to ensure more holistically imagined and designed products.

Target Audience

Product Owners, Product Managers, Architects, Designers

Prerequisite

Basic knowledge of typical backlog management in Agile environments

schedule Submitted 2 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked vinaya muralidharan
    keyboard_arrow_down

    vinaya muralidharan - Psst...your data could be lying to you!

    vinaya muralidharan
    vinaya muralidharan
    Agile Coach
    Capgemini
    schedule 1 week ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Lies, damned lies and Statistics!

    (the phrase is frequently attributed to the British Prime Minister Benjamin Disraeli).

    Many of us work in environments that value Agility or are at least attempting to be more Agile.

    We frequently turn to data, metrics, reports to help us navigate through our complex software environments, to help make sense of what's happening, to support subjective information we see around us and gain insights about the way we work.

    But with the myriad of reports and metrics available to us, it is easy to misinterpret, over-analyze, overlook and generally make a big mess of things.

    Through this talk, I will present some of the popular Agile reports and metrics and how they can be misread.

    I will also share tips of how to counter some of these "lies".

  • Liked Mangalam Nandakumar
    keyboard_arrow_down

    Mangalam Nandakumar - Why story points make no sense for a product company

    45 mins
    Talk
    Advanced

    T-shirt sizing. Fruit Sizing. Planning pokers. You might be familiar with any or all of these estimation (relative sizing) techniques. Story points based estimations (along with velocity mapping) is touted as a predictable method to plan for software delivery. Teams are expected to get a good sense of the effort needed to deliver a piece of work by comparing estimates with references of similarly complex work they have delivered in the past.

    The accuracy of point based estimates fares more or less in the same range as sheer gut feel. So, the natural inclination for software teams is to try and make it more accurate than gut feel. Thereby, we obsess with breaking functionality into smaller byte sized stories. We freak out when there is "scope creep". We debate endlessly about ideal days vs. person days. We fuss over the specific visual representation for the burn-up or burn-down.

    Does it matter anymore how many days the team spent chipping hard at a feature that added no value to the business? Have we made agile teams into mini waterfall teams by focussing on the wrong metrics? Can product companies afford this?

    Process heaviness in product companies can cost a lot. We need to find better ways to invest in success metrics. We need to change the conversation from productivity to value add.

    My talk intends to challenge prevalent estimation practices and contest their validity in product companies. I will also introduce ideas around capturing relevant business metrics and sizing stories using business value.

  • Liked Henny portman
    keyboard_arrow_down

    Henny portman - Will the project manager and PMO disappear in the agile world

    Henny portman
    Henny portman
    Partner
    HWP Consulting
    schedule 2 weeks ago
    Sold Out!
    45 mins
    Talk
    Beginner

    I will focus on a possible transition of organizations who are introducing the agile way of working. Starting with a traditional project setup using permanent PMO (portfolio level) and a temporary PMO (project level). What will happen if the keep the team together as an agile team. What does that mean for the project manager. I will continue my story by adding an agile team. Coordination between the teams can be managed by a scrum of scrum. Still no need for a project organization with a project manager and a project board and no need for a temporary PMO. I add more teams and the coordination asks for a project manager. What dos this mean for a PMO? We can continue and institutionalize the coordination by using frameworks like Nexus, S@S, SAFe et cetera and has an Integration Manager, a Roadmap Manager or a Release Train Engineer and Product managers and Product Owners. I will add some new to be created teams (aks for a Project Manager to organise) et cetera. I will end with an overview and positioning of different agile frameworks and the role of the permanent PMO (focus portfolio management and Center of Excellence) in an agile world.