Stakeholders
- Who has problems that this product or team addresses. Anyone who is impacted by one or more ways by the product whether that be from a user or financial perspective (ex: sponsor) is a stakeholder
- It is in your best interest to understand what our individual stakeholders would to see to feel comfortable about product development. By understanding the business goals your product is supposed to achieve, you can push back and say no to requests that don’t align with the businesses current focus.
Problems
- Typically can be broken down into sub problems that can be individually addressed.
User Story writing terminology
User stories are an output of researching and working with customers to understand problems keeping them from desired end states. Knowing the desired end state allows you to understand the underlying reason why a problem (from customer’s perspective) should be addressed. If a customer tells you features to add but you don’t understand the underlying reason why that feature will be helpful, you should dig in to fill that knowledge gap. Customers don’t always know the best solutions to their problems so doing this due dillegencce will safeguard your team from wasted work.
- User story – what capability/feature to add for users. A user story articulates the problem it solves for user. Solving the problem should lead to an outcome that improves a business goal metric
- Common format: As (user) I want (what/x) so that (why)
- Common format: As (user) I want (what/x) so that (why)
- Acceptance criteria – how to know the story is actually complete and implemented. These criteria measure the success of the development process, ensuring that the delivered functionality aligns with the user’s requirements.
- Common format: Given [x], when [y] happens, then [z] should happen
- Epic – “big” story that can’t be done in a sprint. Epics allow the team to break down the big story into smaller user stories that can fit in a sprint.
PI planning
- Within a determined time frame, select backlog amount (stories) that fit into that time frame and articulate the business kpi/objectives you’ll impact from completing those stories.
KPI
Discussed here.
How to prioritize
Prioritization is firstly based on business objectives. From there, you figure out the desired end states of your customer, uncover the problems and challenges keeping them from that end state, and select the problems that if solved, will help the customer and also achieve the business goals you’re responsible for. Logically speaking, customer problems that won’t produce an impact that simultaneously achieves a business objective should be deprioritized.
Having this clarity is what allows you to say no to the myriad of requests presented to you. It will be in your interest to know what business objective you’re responsible for, have that document and approved by management, and make sure everything you’re team is executing aligns with your assigned objectives. It will also behoove you to document how the work you’re team is completing achieves business objectives for stakeholders to review if necessary.
MVP
Cheapest and fastest way to solve a customer problem while accepting that different aspects of the solution can be enhanced to improve usability, efficiency, etc. More on MVPs here.
Enhancing a product
After you create your core set of features to address the problems you’re targeting you typically move into a phase of continuous improvement driven by customer feedback and observation.
