Product Management

We want our products to be useful for our users. We also don't want to lose time building something that isn't useful or that doesn't fit well into other features of the system. Therefore each team needs a Product Owner.

Hero Icon

4 rules in our product management

  • Great understanding of users’ needs, personas
  • The backlog is well-described and maintained
  • User Stories are granular so that every developer delivers multiple stories per iteration
  • User Stories have acceptance criteria

Understanding of users' needs and personas

I get it, most of us played with computers as kids or teenagers. We all enjoyed the moment we wrote `tar` arguments right and when `httpd` or `nginx` configuration wasn't difficult anymore.

All this is amplified by the fact we more often than not pick Clojure as our language of choice. A language that is a classic example of *nerd-choice* (in the best possible meaning of this word).

Yet, all we do is for end users. The whole point of all apps we build is to create something useful.

For that reason, each team member, be it a developer, a designer, a tester or another role, must be one hundred percent sure he/she knows:

  • What types of users are going to use this system?
  • What devices are they going to use and in what contexts?
  • How tech-savvy these users are.
  • Most importantly, why are these users opening the app and what do they want to achieve?
image_1

Everyone who is being onboarded should test the product from all personas. If the product is not in version 1.0 yet, at least should see all screens and click through prototypes in Figma.

The backlog well well-described and maintained

A good well-maintained backlog is a digital twin of a product. It contains facts about things that have been done. And it contains plans about what the team will do next. In pre v1.0 phase, the backlog should contain all tasks that lead from zero to one.

There are the following types of tasks:

User Stories

User Stories

little kings of the backlog, tasks that provide something useful for the user.

Bug svg

Bugs

no matter how much we try, inevitable part of our lives.

Technical tasks svg

Technical tasks

refactoring, setting up CI/CD, upgrading libraries, you know this. These shouldn't be overused when splitting large User Stories gets difficult.

image_2

Every task in the backlog should be a correct stage, with the assigned correct person and other attributes the team will decide for in its methodology.

User Stories should have acceptance criteria. More about it below

Bugs should lead either to a way how to replicate the bug and/or should describe exactly what is expected behavior and current behavior.

Technical tasks can get very technical and they are generally not managed by the PO, but by the team. So if the team has non-technical PO, you don't have to feel bad for using words like CSRF, master-slave, or other cryptic terminology.

User Stories granularity

In an ideal case, each User Story should not need 1 day of work. Realistically, a User Story shouldn't even need more than 3 days. But always target ±1 day of work or smaller.

User Stories can be difficult to split. Do not jump into splitting tech tasks too early.

  • Split by flow

    if there are multiple steps, you can turn every step into a US

  • Split by persona/role

    if the behavior is different for different system roles, split behavior per role

  • Split by UI part

    if you have multiple UI components, you can split them by these components. Proper datagrid can be split into DataTable view of all records with 2 improvement User Stories (add filtering, add pagination) for example.

  • Split by Must have / Nice to have

    first implement necessary functionality and then add the rest. First, create a form with server-side validation, then add client-side validation (this is adding a value for the user, so it can be formulated as US)

User Stories have acceptance criteria

User Stories should have acceptance criteria. Acceptance criteria should use Gherkin Syntax (https://cucumber.io/docs/gherkin/).

Example of acceptance criteria:

Given user is signed in as Sales analyst

And user is on Sales Dashboard page

When new BI data are processed

Then the Sales Dashboard automatically refreshes data in less than 10 seconds

It's reasonable to expect multiple acceptance criteria per User Story. If UX is very descriptive, don't overdo it.

Take it as an optional suggestion, but Acceptance Test-Driven development (https://en.wikipedia.org/wiki/Acceptance_test-driven_development) is recommended. If the Product Owner is mature enough and so is the team development infrastructure, this should be at least trialed in the team

Blue background

Get in touch

Book a free consultation meeting with us

Lets discuss your idea