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.
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?
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
little kings of the backlog, tasks that provide something useful for the user.
Bugs
no matter how much we try, inevitable part of our lives.
Technical tasks
refactoring, setting up CI/CD, upgrading libraries, you know this. These shouldn't be overused when splitting large User Stories gets difficult.
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
Join Our Webinar!
What is Craftsmanship? How Does It Relate to Agile
- Principles of software craftsmanship. - Overview of agile practices. - How craftsmanship improves agile. - Real-world examples from Flexiana. - Best practices fro agile teams.
16
October
07:00 PM
CET