Intro
From my point of view, if there are great described requirements, it will increase the speed of product creation and significantly reduce maintenance & development costs. So, everyone wins in this case:
- There are great requirements provided from the start of product creation
- The development team understands what should be exactly done
- Based on PO’s requirements, QAs can properly test what developers did
- Stakeholders/customers are satisfied by getting results -> the great product
Unfortunately, I saw many times that business doesn’t want to spend resources on Product Owners, Business Analyst, some of them like to participate in the creation of requirements by themselves instead of giving this quite a hard task to professionals. In certain cases, business representatives who are working on requirements cannot cover all questions, all cases of product behavior, etc. And the development process could go down: the requirements’ creator (stakeholder) is not responding because of not having free time for covering every aspect of the product, devs are waiting for the answers to be unblocked and struggling to do something without any customers’ approval (because there is no answer).
Or the case when there are no requirements at all and customers say: Please do like this competitor, but much better. It’s the ‘best‘ scenario, which causes a lot of non-properly spent resources. Requirements for software products should be created and highlighted as a high-priority point.
No requirements – not a problem, devs can build something, they’re clever.
Herman | pownery.com
No great requirements from the start = no great product at the end.
So, let’s have a look at what the great requirements are, and how they can reduce development costs and increase the speed of product creation in practice.
Note: First, you have to understand, it takes time to create great requirements for developers. So be patient because the better you describe features, the better developers complete them.
0. Main idea / vision
The main direction of the software product provided by stakeholders/customers is dramatically important. Without having a clear vision of what a product is about, will lead the development process to nothing. Sure, the product owner can find out the product vision and define, which product’s purpose, and try to find the market needs, but it’s another story. Providing the idea to everyone on the team (developers, managers, designer) is the 1st step to getting great final results.
Note: Especially working on giant products, sometimes developers even cannot see the final results on which they have been working. It’s disappointing, isn’t it? So if every teammate understands why create this product, and what value it brings, then the development has started being more conscious, development teams get more involved, and people make a much more impact.
My advice:
- Define the main idea / vision of the product.
- It should be transparent and clear, why and who will use the product
- Do not continue gathering requirements if the product vision isn’t defined!
1. Business Objective
Having a product vision is great. But every product has parts that should be separately developed. Each of these parts is a different item: milestone, epic, feature, task, etc. So each increment of the product should have a business objective to make the value transparent for everyone: from developers to investors and vice versa. I’d say more: even a task inside the feature has its business objective: why we develop it, what the business need from the task, and which issue or request it should resolve.
Probably, you saw tasks, which contain only a title, or contain a title and a few words of what the customer expects, or a title + a few words + a picture of an example of how it should approximately look. Did you see such? Did you create something similar? 🙂
My advice:
- Provide the general business objective for every item of the product, which will be developed, designed, tested, etc.
- A business objective gives a clear picture of what should exist at the end of development within a certain task or feature.
- Deprecate the task of the feature, when there is no business objective to do it. It can avoid the wasting of development resources.
2. Description
I would say, this is the most important part and at the same time optional if you apply all principles by creating requirements in this article. As a minimum, your tasks and features have to have a description to demonstrate to developers what this feature is about. Just remember:
No empty tasks, please, and no not described features. Having a description will reduce development costs significantly.
Herman | pownery.com
Sure, it could be a case when we create a task to provide access to some services and the title can talk about itself. But even here, you have to describe to whom you should give access, to which credentials, which permissions, etc.
My advice:
- The better you described the task, the fewer questions you get
- The fewer questions you get, the less time developers and you spend on clarification.
- Do not think when your tasks are clear without any written explanation. It’s a big mistake. People are different, everyone can understand differently what you mean.
3. User story & Scenarios
That is my favorite part of a certain article. User stories can cover almost everything. You describe here the main action that a user is expecting to see at the end of a certain feature. And scenarios cover every step, what’s exactly going on with the behavior of the product.
- I elaborated on the creation of the perfect User story & Scenarios for this article. You can follow this link to read: A Guide to Maximizing Value of User Stories
In a long story short, User Stories and Scenarios include the following structure:
– – – – –
AS A [particular user, role]
I WANT TO [expected action]
SO THAT [the reason why to do it]
Scenario # – User doing something
GIVEN THAT: I’m a user
WHEN: I do something
THEN: something happens
– – – – –
Providing such details allows decreasing a lot of incoming questions from developers and QAs. Also, scenarios are going to be Acceptance Criteria. When all scenarios have been implemented correctly, and it works as expected based on scenarios, it means the feature has been done.
Quick question: what indicates the seniority of the Product Manager / Product Owner?
Right, Senior PO has to describe not only Happy Path (getting a result from A to B) but Error and Empty States (what happens when nothing happens). The more aspects of the feature behavior have been included, the better the quality and UX of the end product.
Sure, you cannot cover everything, that’s why you meet the developers and QAs, and you’re discussing what happens in this case, what happens if the user dropped out, what if the user changed internet connection, etc. It’s a topic for another article.
UPD: here is this article:
Error states, Empty states: Why to add Negative cases?
4. Technical details
Let’s be honest. Often product managers and POs aren’t developers and even more – aren’t technical architects. Probably, you have basic skills to build a simple website or mobile application. When you worked as a software engineer and later became a Product owner – you should use these principles 🙂
So, you don’t know everything about development, and it’s okay. That’s why there is a huge number of roles in the software development industry that help you to build a great product.
Ideally, either the most Senior Software Engineer or Architect should provide technical details to the feature or tasks (architecture scheme, recommendation to use existing endpoints or create the new one, etc.) which you may not know. You are a business representative, and your role is to provide a business idea with high-quality requirements and why the business needs this feature.
But if you can do this, just do it. It can be simple, but at the same time, these details can simplify the development.
– – – – –
For example:
The action button has the following CSS styles: font-size: 20px; background-color: #fffff; .btn-class:hover {border-radius: 1px}
or
For better page load speed, paste all JS scripts from <head> to the footer. Based on Google’s recommendations, it has to speed up the load metrics.
– – – – –
Moreover, developers can leave their notes because it’s their space to work. By the way, it makes the development process because you can ask developers why you use this approach or this one and don’t hesitate to request for providing technical details in a more native language to you. At the same time, the Product owner has to understand what happens on a low level.
5. Metrics
It’s rather an optional point because sometimes there are no metrics to measure the final implementation.
For example, you build an E-commerce product. You definitely should include the shopping cart or the place where the users can overview everything they added for purchasing, right? It’s obvious, users will go to the shopping cart, and no need to describe what number of unique clicks you expect to get. It’s analytic’s stuff, not requirements.
Nevertheless, when it requires measuring or improving something, you have to write metrics you’re expecting to see: page load speed, implementing some feature to increase CR, developing automatically adjusting placement for unique goods based on your smartphone data to decrease bounce rate or make average purchase metrics higher, etc.
My advice:
- Include metrics you expect to see after implementing the feature
- No one can argue when numbers have been declared: either you get these numbers, or not.
- Try to include metrics everywhere it’s required and suggest where it isn’t. It won’t disturb developers and QAs
6. Design
To have user stories, business objectives and scenarios are great. But to include a design screen and show the different states of the product is wonderful. Developers see the whole picture of what should be at the end of the implementation. Even describing “Users click here (design) and it happens there (design)” will dramatically reduce the number of questions for you and stakeholders. That means, developers and you spend less time and can concentrate on more important things.
There are cases when you cannot include any design screens because there is no design or your part of the product doesn’t require any designs. It’s especially related to non-functional requirements where you’re describing behavior besides direct user interaction.
For example: add page-downloading (preloading) when the user is on this page because users are dropping out on a certain step by waiting until the page is fully loaded, so show the all next pages instantly after the users initiate opening.
7. Estimation / Expectation
Each business would like to know when it’s done. It’s obvious. When there is no timeline and estimation, how everyone knows when it should be delivered?
First, as a Product Owner, you have to know stakeholders’ expectations. Work on that to clarify if you didn’t hear any expectations yet! Then you can create requirements that have to be reviewed by developers. Developers have to estimate ‘how much’ time it costs to deliver. Knowing customer’s expectations and developers’ estimations, you can predict and define if this scope is enough to cover expectations, or if the scope is too huge, and it does make sense to reduce it.
If you discussed expectations, you see the whole picture. You can decide what to include in the scope, and what can wait.
Herman | pownery.com
From this point, either you will leave it as it is or change requirements. It’s up to you to rewrite it. Do you see how this parameter can influence your final requirements? Do not ignore that point!
8. Dependents / relation
It doesn’t make sense the creating of scheduling feature for emails if no email service sends emails directly, right? It doesn’t.
Creating relations between features is significant because stakeholders understand why this feature won’t be done before that feature is implemented, and developers can see what should be created first and what to be expected further to do.
There are so many cases when no one marked that ‘it’s a dependent for this feature’ and later it produces a lot of bugs because no one took into account the certain dependent. That means you spend more time fixing bugs, maintaining, and resolving more potential issues. In a long story short, it increases development costs. No one would like to have such problems. The more relations you mark, the fewer resources you spend on development.
My advice:
- Mark as many relations as possible. Everyone will say ‘Thank you’, even you to yourself.
- Some relations (part of a product) can be developed in parallel, but make sure about this new dependent – these parts should be merged and be workable. Mark it.
- Dependents should be clear, especially for stakeholders: an impediment could be just an outdated subscription to a critical service. It should be paid to unblock the dev team.
9. Comments / updates
At first glance, it’s easy to implement. It doesn’t cost anything to open the task and leave a comment about the requirements that have been changed, business needs some other thing. But in real life, a few people do it. Why is it hard? Because someone used to forget to do that. People do not count it as important stuff, which is bad for the product.
No feedback, and no communication = no great product at the end.
Herman | pownery.com
When stakeholders commented that there are changes, requirements should be updated. Sure, if it often happens and after the development of the feature has been started, it’s the worst scenario: devs have to re-estimate, clarify and change their approach if there are dramatically huge changes. But it’s about commitment and agreement.
The main idea is to keep requirements up-to-date. Anyway, the business pays for the product and the business decides what they need. You as a Product Manager / Product Owner can advise, propose and find out the best option to develop it. Keep it in mind.
10. Agreement
The agreement is the fundamental point of any cooperation. Why is it related to perfect requirements? You cannot build great requirements if stakeholders change priority every day / week / month, if they change expectations for release dates. It’s impossible to maintain all previously created requirements because of constant changes and dates of releases. It produces chaos (believe me!)
So, you have to find a way how to agree with the delivery: in this period, we delivered this as you requested before. Please, let’s agree that we’re working on a certain scope. You have to explain that refocusing costs money too.
Let’s imagine, developers work on a feature for around 2 weeks, later priorities have been changed, and they have to work on another. Then back to the first feature.
Result: the first feature isn’t done and developers need to remind what they have developed (it takes time too), and maybe set up the environment again, the second feature isn’t done, they came back to the first one. Resources are spent, but no features are delivered at all. Having an agreement reduces development costs. Stakeholders, devs and you have to understand it.
My advice:
- Agree with stakeholders / customers about some milestones: which scope to which date should be delivered
- Try to make these agreements consistent: not one time, but regularly
- Explain the value of why it’s important to follow the plan and which consequences it brings by changing priorities and scope
Bonus
First, I’d say thank you for reading this article. I appreciate that you spent time, I hope you’ve learned a bunch of new stuff. You can use this format in your products / projects.
Here is an empty template. This one was the most effective template for getting the best result without spending time for clarification, suggestion and it helped deliver high-quality features:
– – – – –
Business Objective
explain_here
Design screens
paste_design_screen
User Story
AS A [who]
I WANT [what]
SO THAT [why]
AND [why, if needed]
Scenarios
Scenario # – Action
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
Scenario # – Action
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
Business Requirements
clarify_additional_business_logic
Technical Notes
tech_notes_by_developer
Additional links
link_to_prototype_or_design_or_any_useful_source
– – – – –
Do me a favor
If you liked this article, share it with your colleagues on LinkedIn, in social networks. Let me know if you have some questions via the contact on LinkedIn.
Good luck and God bless you.
