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.

 
3 favorite thumb_down thumb_up 6 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 8 months ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Shijo Paul
    By Shijo Paul  ~  8 months ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • Relevant topic. I like the focus of the subject and the supporting materials

    I think the submission could be improved by:

    • Have you considered adding the things you listed as part of DoD or including them into every backlog item, than a separate backlog item? May be present some practical implications of both approaches as well.
    • vinaya muralidharan
      By vinaya muralidharan  ~  8 months ago
      reply Reply

      Hi Shijo

      Thanks for your comment. 

      I do plan to talk about it, like you mentioned, as one possible approach. And you are right that it is important to highlight the practical implications of different approaches. I will give it even more thought and will plan to cover it, if the topic is selected.

      Kind Regards

      Vinaya

       

  • Vishal Prasad
    By Vishal Prasad  ~  8 months ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • I generally like this topic, effective product backlog management is more said than done.
    • Would you be kind enough to share few examples with me or direct me to a blog so I get a better idea about your content please? Unlike other conferences, Vijay Wade always takes accountability of everything said at APGI, so I just wish to be a bit thorough.

    I think the submission could be improved by:

    • a little adjustment to time will be needed. 
    • vinaya muralidharan
      By vinaya muralidharan  ~  8 months ago
      reply Reply

      Hi Vishal

      Thanks for your comment.

      I will try to elaborate some of the ideas I have for this topic.

      As a product manager or a product owner, one focuses a lot on the functionalities on offer. Also there is increased focus on aspects like performance, maintainability, operability etc.

      I would like to highlight some additional aspects – accessibility (for differently-abled persons), inclusivity (of all groups irrespective of gender, age, industry, etc), internationalization (language options, international standards and metrics) and sustainability/eco-friendliness.

       

      An example of building in Accessibility into the product roadmap or backlog - could mean taking into consideration color-blind users of a product, for instance.

      This could mean not relying on color to communicate (red for alert/green for ok etc).

       

      An example of Inclusivity could mean that a social networking site includes features to filter out comments which are offensive or threatening to women, for instance.

       

      In addition to highlighting these -ilities that product managers need to take into considerations, I would like to share some tips for how to go about ensuring that our product backlog includes these aspects.

      These how-to ideas would include creating diverse user personas, having inclusive product discovery teams etc.

       

      Hope this helps - please let me know if you would like any further details.

      Kind Regards

      Vinaya

      • Vishal Prasad
        By Vishal Prasad  ~  8 months ago
        reply Reply

        Thanks for the details Vinaya, looks good.

  • Srinivas C
    By Srinivas C  ~  8 months ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • ...Generally good idea, and she is a good presenter, I'm inclined to say we should accept this.

    I think the submission could be improved by:

    • ...

  • Liked Srinivas C
    keyboard_arrow_down

    Srinivas C / Dan R Greening / Payal Dev - ScrumMaster Master Class

    90 Mins
    Workshop
    Advanced

    ScrumMaster who take their role seriously are beset with difficulties. As a process Owner and problem solver, the issues are many and systemic fixes needed. So what can/should they do? As with many other competencies, problem solving needs practice. Here we confront a fictitious case-study (based on two real projects) with help from India's first Scrum coach. As he takes you through the thicket of a complex situation (aren't all real situations complex, and not just "complicated"?) you will get a series of in-depth example SM situations. Further a moderated discussion on how to handle them. Some will be your own. This will be different from a Certified Advanced ScrumMaster class, this doesn't have much coaching content, but a strong problem solving slant.

    NOTE: Case study here is of a "cummulative" type, which allows drawing wider lessons based on familiar common experience. The situation is meant to illustrate common (and one or two not so common) problems and their treatment.

  • Liked Ritabrata Moitra
    keyboard_arrow_down

    Ritabrata Moitra - The Why and How of Trunk Based Development

    45 Mins
    Talk
    Intermediate

    Background

    A variety of branching strategies exist in the delivery universe as of date. Having worked with multiple of these, in my personal experience, I have explored the pains and gains that each of these strategies have to offer. While there are certain situations or delivery patterns that might make a certain strategy a better fit, in my experience, Trunk Based development usually is the most sane way of writing, maintaining and delivering production code.

    Approach

    Trunk Based development is a source-control branching model where developers push code ( of all possible features that are in development ) on to a single remote branch, referred to as the trunk. Developers at all costs try and resist the urge to create other long-lived development branches. This is important because developers, including myself, are mostly lazy. So if there is something that can ease their lives off today, they would rather do that knowing that they are up for a hard day in the future. This is mostly the paradigm of not developing on the trunk. Branching by features makes it easy for development teams in the shorter run. However a developer is well aware that he is going to stay up late in office the moment his project manager says that the code he has written on the trunk has to be released. What follows is merge hells, integration nightmares, bugs, angry developers and divorces.

    Findings

    In my career, I have worked with a bunch of branching strategies up and until now. While it is indeed easier in the shorter run to create feature or team-specific branches, it is almost always a painful and tedious job to bring things back into the master in order to release. Also in my opinion, other branching strategies defeat the entire purpose of Continuous integration since not ALL the code that is being written is being tested in unison.

  • Liked Mukta
    keyboard_arrow_down

    Mukta - The adverse impact of mind-set on CI/CD.

    Mukta
    Mukta
    CEO
    Crevise
    schedule 8 months ago
    Sold Out!
    45 Mins
    Case Study
    Advanced

    CI/CD are crucial practices to adopt for agile delivery success. The effective usage of continuous integration is contingent upon the average programmers state of mind under pressure. Replication of build-server environment and bringing forward as many steps of error-checking (verification) as possible can lead to huge saving of re-work. Conversely a good CI set up introduced mid-stream in a project has the social side effect of diluting the power of the very CI facilities which can bring about benefits in terms of increased quality and quick delivery.

    In this talk the overall interplay between CI set up and the developer's mind-set is analysed. In-depth examples of SCA on Java/JavaScript code with alternate configurations to demonstrate the effect. We also touch upon Definition of Done for a wider context. We draw a handful of conclusions on how to configure SCA.

  • Liked Vijay Wade
    keyboard_arrow_down

    Vijay Wade - Combinatorial Array based Testing : Agile Testing - Way to reduce your test set

    45 Mins
    Talk
    Intermediate

    Almost all products in this world are not entirely tested only because -

    • They can not wait for exhaustive tests to happen
    • They do not know how to get the 100 exhaustive test suits.

    Combinatorial Array is the new breakthrough in the Testing Algorithm. It reduces your test suit by 10 times or more. This Presentation will take you deep in to what Orthogonal Array based Testing is , its limitations, the solutions by CT.

    This is one way you can make your testing Agile and also makes your test coverage 100%

  • Liked Siddharth Kulkarni
    keyboard_arrow_down

    Siddharth Kulkarni - Dr Culture Shock - Or How I stopped worrying and embraced Org Culture

    45 Mins
    Talk
    Intermediate

    The org culture mantra is usually considered a silicon valley mumbo jumbo. Although many companies and teams rant about culture, very few in my opinion take it seriously. In this talk I would like to discuss the importance of Org culture and how it makes or breaks businesses and teams. I will lay out some key pointers that will help the influencers in the audience make decisions about their org or team culture. The talk will be in the context of culture in tech companies.

  • Liked vinaya muralidharan
    keyboard_arrow_down

    vinaya muralidharan / Carol Mathrani - Let's build that Dream Team!

    45 Mins
    Talk
    Advanced

    What would a dream Agile team look like? A small, collocated, cross-functional, self-organizing feature team?

    Not always. There are several considerations that go into forming a team and there is no one-size-fits-all solution.

    While the above described team attributes may help us be agile, there may be other conflicting goals which may nudge us in a different direction.

    For anyone trying to design and set up a team, it is important to be aware of the many possibilities and the many goals that may influence team configurations.

    Through this talk and with the aid of some hands-on exercises, we will aim to throw light on various aspects of team formation and the pros and cons of the choices we make.

  • Dan R Greening
    Dan R Greening
    Managing Director
    Senex Rex
    schedule 8 months ago
    Sold Out!
    180 Mins
    Workshop
    Beginner

    Agile isn't just for software, it's for your thing, whatever that is. In my keynote talk, Agile for Everything, I introduced six fundamental patterns that comprise Agility. They apply not just to software, but to virtually any situation where rapid adaptation can improve success.

    In this workshop, I'll teach and coach you to apply those six principles to your thing. "Your thing" might be marketing, UX design, software, finance, hardware, business development, product management, your company, your family, your career, a classroom, your education, your kids' education, an art project, or building a house. Or it might be something else.

    You gain two ways attending this workshop: First, you will get coaching help in achieving "your thing," whatever that is. Second, you will gain an intuitive, visceral understanding of agility—its strengths and limitations, its nuances and quirks. That understanding will help you rapidly assess agile opportunities and dangers, and will help you teach and coach in more fruitful ways.

  • Liked Carol Mathrani
    keyboard_arrow_down

    Carol Mathrani - Batman or Justice League - A 10x developer or 100x scrum team

    Carol Mathrani
    Carol Mathrani
    Agile Coach
    Employed
    schedule 8 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    There are many discussions around 10x developers and the need to have one - 10x instead of a few average developers. But why do we limit ourselves to individual heroes when we can focus on building an entire team of 100x potential. Its not like we dont need the 10x developers - but our necessity lies in having the 10x build a 100x team. The building of such teams should start within the organization, from among are very good programmers, not necessarily a 10x. As we propagate in scrum - a cross functional team that creates a working software together, with key characteristics of accountability, ownership and self managing. building them with a 100x scrum team concept