| description |
|---|
An overview of common terms that come up during the product development cycle. |
Agile product management is an iterative process. It’s based on gathering user feedback and adapting accordingly. It helps product teams reduce waste through iterative work sprints. An Agile process is driven by the completion of stories, each of which provides tangible, demonstrable value to the user/customer/stakeholder.
A widely-used software development method, and a subsection of Agile Development
GitHub is a code hosting platform for version control and collaboration. Projects can be hosted on the site and developers and Product Managers can view repositories of code and collaborate on them.
On Github, issues can be used to communicate between the project manager and development team. They can act as more than just a place to report software bugs. You can collect user feedback, report software bugs, and organise tasks you'd like to accomplish with issues in a repository.
A MVP is an early version of a product launched quickly in order to gather user feedback earlier in the product life cycle. It has just enough features to satisfy early customers and provide feedback for future product development.
A problem statement is one line that recasts the idea in human terms of what the technology allows your user to accomplish. They are expressed in one sentence, following a common template: "The user needs a way to do something (that addresses their needs) so that something happens (that benefits them)”
Example: As a teenager who struggles to connect with others**, I’d like a way to** learn social cues so I can find friends and build relationships with my peers.
The Product Backlog is a list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for managing the Product Backlog.
The Product Manager creates the vision and direction for the product and then develops detailed plans on how to turn the vision into actual product features. Their responsibilities include setting business objectives, managing the product team, researching and testing with users, collecting data and stakeholder management. They need to possess sector and domain expertise. As opposed to Product Owners, Product Managers are strategic, they focus on the product’s vision, company objectives, and the market.
The Product Owner is a specific one-person role within the Scrum framework, which may be provided by the client or sit within the agency. As the product lead with your charity, you are predestined to act as a PO due to your business know-how and corporate authority. During the build phase, the product owner has three primary responsibilities. As opposed to Product Managers, Product Owners are more tactical. They translate the Product Manager’s strategy into actionable tasks, and work with cross-functional agile teams to make sure they are executing on those requirements.
A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you are building. A roadmap is a guiding strategic document as well as a plan for executing the strategy.
Pull requests are the heart of collaboration on GitHub. When you open a pull request, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch.
Pull requests show diffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.
On GitHub, a repository is usually used to organise a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs.
A scrum master is the facilitator for an Agile development team; they are responsible for managing the process, and only the process. They are not involved in the decision-making, but act as a lodestar to guide the team through the scrum process with their experience and expertise. People filling this role have to lead from a position of influence, often taking a servant-leadership stance.
Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realising the Sprint Goal. The Sprint Backlog should include the highest prioritized items from the Product Backlog. As opposed to the Product Backlog, the Sprint Backlog should remain undisturbed if at all possible. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
The Sprint Goal is an objective to be met by the Sprint through the implementation of part of the Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. It should be measurable, focused and clear.
Bad example: Enhance shopping cart functionality.
Good example: Streamline purchasing process to enable an increase in conversion rates.
Sprint Planning is a regular event in the Scrum framework where the team determines the Product Backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The PO is responsible for leading the Sprint Planning.
The Sprint Retrospective is a meeting for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. It occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The PO should attend the Sprint Retrospective.
A Sprint Review is an informal meeting held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. It is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Sprint Review is led by the PO.
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1.
A user journey is a series of steps (typically 4-12) which represent a scenario in which a user might interact with the product. They can be used to demonstrate the way users currently interact with the product or describe the way users could interact with the product. They are usually created towards the beginning of a project, after user personas.
User personas are representations of clusters of users with similar needs, goals, and behaviours. A persona is a single individual that represents a group.
User Research is conducted so as to understand users’ characteristics, aims, and behaviours towards achieving their aims. User Research helps place people at the centre of your design process and your products.
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. Stories are the building blocks of Agile projects and represent the fundamental unit of communication and tracking progress.They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.
User testing is the process through which the interface and functions of a website, app, product, or service are tested by real users who perform specific tasks in realistic conditions. The purpose of this process is to evaluate the usability of that website or app and to decide whether the product is ready to be launched for real users.
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated by totaling the Story Points for all fully completed User Stories during a sprint. After a few Sprints the velocity of a Scrum Team will most likely be predictable and would allow quite accurate estimation about the time needed until all entries in the Scrum Product Backlog will be completed
An important rule for calculating the velocity is that only stories that are completed at the end of the iteration are counted. Counting partially finished work (e.g. coding only - test missing) is strictly forbidden.