Once upon a time, there was a client, wise beyond his age, comprehensive and kind, full of life and ideas. One day, he met a magical Product Manager who could read the minds of all the subjects in the client’s system and knew exactly what they needed. The client was so delighted learning that such a partner existed that he thought it would be wise to become friends, and they both worked together on their products from that moment on…
…and they lived happily ever after.
What a wonderful ending. If it were only true. As a Product Manager, with 6+ years of experience, meeting the requirements of each client I had the pleasure of working with (and to be honest, some unpleasant clients too) was not a simple task. The challenges and ideas are always coming and constantly change. So, if I could go back once again to the story at the top, I would say that there was no plot, and that’s the reality which takes place. We are not wizards.
The Art of How Stories Turn into Products
Just a few years ago, a common practice among Product Development Teams was to focus upon the functionality of a system operation, without even considering the needs of the users. This means that the kingdom (or system) was created without thinking about who lives in it or about their needs. Selfish.
Nowadays, teams understand that the subjects, or in this case users, should be the main focus of thought before developing and testing a product. If you’re not able to understand the user’s needs aptly, it won’t matter how well you execute the rest of the product.
If you haven’t guessed by now (it’s ok if you didn’t), the Product Manager (PM) is, in fact, the writer of the story, putting itself as a character. PMs are in charge of creating rules (or requirements) for the the users to interact with the system.
Seems hard to tell what requirements can even be, but rest assured, it’s not so. Since a Product Manager has control over the story, it’s important to define and describe what the requirements are and when to create them.
For Product Development Teams, a traditional requirement would not consider users yet. They are created before the planning begins, as text, flowcharts of constraints, conditions or capabilities for the system.
Even with requirements, you need to set up which of them will really work for the system and which will not. Think of requirements as ‘laws to abide by’. They need to be:
- Complete. As feasible as they can be— no open-ended.
- Testable. Every requirement should be tested.
- Consistent. No conflicts between requirements and links
- Design Free. Should be specified in the business perspective, rather than the software perspective.
- Unambiguous. Related keywords such as “shall” should be used.
Remember that traditional requirements focus on system operation. A common mistake is that they are written in such a way that it is hard to interpret them and no explicit test or acceptance criteria is duly considered.
Traditional requirements are normally treated as a contract between the business and systems development and, as such, completeness, formality and rigidity in requirements is the rule. Once again, no user is considered at all during this kick-off process.
The User Story
As a Project Manager, I’ve learned from Mike Cohn that a user story is really helpful in capturing just enough information about a feature, to facilitate a future conversation between the product manager and the team.
To involve a user, the flowchart should be changed into a narrative text, describing an interaction between the user and the system, focused on the value gains for that user. This narrative is known as a user story. User stories are descriptions of a feature told a person’s perspective who desires new capabilities; usually a user or customer.
For a PM, speaking in terms of agile development, collaboration goes first, and documentation for requirements comes after. Values such as collaboration and ‘just-in-time’ definition are what makes a user story a good agile tool. The same as traditional requirements, a good user story uses the “INVEST” model:
- Independent. Reduced dependencies = easier to plan
- Negotiable. Details added via collaboration
- Valuable. Provides value to the customer
- Estimable. If it’s too big or too vague, then is not estimable
- Small. Something that can be done in less than a week
- Testable. Good acceptance criteria
Writing a User Story
Let’s talk about structure. A proper user story contains:
- Acceptance criteria
For acceptance criteria, you must define conditions to fulfill the story objectives. Here is an example of what a typical and basic user story is, and what the acceptance criteria looks like:
You can practice on building a basic user story and acceptance criteria using the following lines of code:
As a <type of user>,
I want to <perform some task>
So that <I can achieve some goal/benefit/value>.
Given <condition 1>
And <condition 2>
And <condition n>,
When <user performs task>
Then <expected result 1>
And <expected result 2>
And <expected result n>
Take a look at this example:
As a customer,
I want to withdraw cash from an ATM
So that I don’t have to wait in line at the bank.
Given that the source account is creditworthy
And the token is valid
And the dispenser contains cash,
When the customer requests the cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned.
In other words, it shows a cause and effect parameter.
To exemplify a user story’s narrative, read the following paragraph:
“As a [type of user] I [want/can/am able to/need to/etc.] so that [some reason].” Though that format has its advantages, user stories can be in any format, so long as the conversations surrounding the stories occur. User stories come in different sizes. A small story, called simply a “user story”, is one that is well understood and can be implemented within a sprint—something like: “As a manager, I want the monthly sales report to be paginated so that I can quickly refer to a specific part of the document.”
It’s also important to consider the size of a user story; from large stories, typically referred as Epics to something more simple such as tasks. Epics take more than a single sprint to develop and test. The scope is more broad, and most of the times, like a book with chapters, it needs to be split into smaller stories before the product development team can work on them.
‘Sidekicks’ for your Product Development- The Three Amigos
Everyone in the product development process must be involved in telling the proper story. I like to use the concept of the “Three Amigos Process”, as a visual reference. A Product Development Team is composed by 3 characters: a PM, a Product Developer, and a Tester. The constant challenge is to develop efficient communication between them.
At Nolte, we create user stories at the beginning of each project, either starting with design or going straight to the development. We base the user stories definition mainly in the User Flow. When we have this flow defined and ready, the next step is for the PM to write the first draft of the story, with title, description and the initial acceptance criteria.
As many of our projects include an administrative function, it’s also very important to consider the back-end functionality (WP Admin) for each user story definition; we set this inside the same user story that describes the front-end functionality. Also, we tend to identify the types of modules that will be needed to achieve each feature of the product (website, mobile app).
When we have concluded the user story drafting phase, we share this with the team, so they can read and analyze the effort, implications, and unseen relationships between each product feature. Right now, this process is asynchronous + synchronous. Developers and Testers receive the user story, dedicate some time to read them, write down questions, and bring them into the Three Amigos session. At this point, both developers and testers share their questions, insights, and feedback, which results in either accepting, changing or adding elements to the User Stories, especially to the Acceptance Criteria and Test Cases. Our Nolte team doesn’t have an internal testers and, for this reason, we partner with Applause, so the Testing Team Lead is the person that gets involved in this process.
Finally, the User Story is an integral part of the interaction between a Product Development Team and delivering great products. You can start with this but don’t forget to generate an agile environment in which all team members understand their purpose, as a team, and have a shared mindset: generating value to the user. Implementing an Agile approach verbatim can be difficult because of organizational limits, structures or even budgets, but you can always adapt it to your capacity and resources, so you establish the foundation and start iterating on it.
Track Duck published an article about Nolte as a successful case study on Product Development.
If you’re interested in project management, learn about workflows with JIRA.
Avoid common mistakes made by product managers when delivering projects.