You can search for terms in the Search bar above! ;)
The Agile Dictionary
Pair Programming originates from the Extreme Programming (XP) Agile framework in which two developers work together and share a single workstation(one screen, one keyboard and one mouse). The developer at the keyboard is called the driver while the other, the navigator, watches, reviews and provides analytical feedback. The two developers will switch roles frequently. This leads to a resulting code getting 15% fewer defects on average.
Personas (also User-Personas & Customer-Personas) are highly detailed fictional representations of your target users. It usually consists in demographic information like gender, income and age as well as psychographic information like motivations, interests, and frustrations.This helps the Team to understand the users with their preferences and expectations of the product. The Product Owner will refer to this persona when prioritizing features to release from the product backlog. Most of the time this profile is displayed in the Team room.
Persona / User-Persona
Planning Poker is a consensus-based Agile estimating method used to determine how many work days (or working units) different user stories represent. This helps the Team to estimate how many user stories from the product backlog can be taken on a single sprint. The estimating game is recommended to be played with several user stories as humans can estimate better by comparing things rather than giving a value to a single one. Every Team member will attribute a value card to each user story representing their work days estimate. Cards use the Fibonacci values (1,2,3,5,8,13,20,40) as it is simpler for people to differentiate.
These are the different steps:
To start the planning session, the Customer or the Product Owner reads the user stories and describe the features to the Team (estimators)
Team members estimate the work days for each user story by placing numbered cards face-down to the table to avoid cognitive bias of anchoring
Cards are then displayed face-up at the same time
The estimates are then discussed and high and low estimates are explained
The process is repeated as needed until estimates converge and consensus is naturally attained
A Product Backlog is an ever-evolving list of product requirements that bring value to the product by meeting customer needs. It should be the single source of requirements for any changes to be made to the product. The Product Owner is typically in charge of building, ordering and maintaining the Product Backlog. As the product evolves, the Product Backlog gets more complex. The Product Backlog refinement consists in adding details, time estimates and prioritization order of the different items. All items are reviewed and revised. Prioritization is often done with the customer to order items by business value.
Agile team typically create a sub-backlog containing the top entries for each development iteration known as an iteration backlog or sprint backlog.
Sprint Backlog, Iteration Backlog
The Product Owner (PO) is the member of the Scrum Team who understands the product, the business, and the market requirements. They are responsible for building and maintaining the Product Backlog containing user stories, prioritizing them and make sure the product deliverables match the customer needs. The PO also has to make sure that work items are clear for everyone.
A Product Roadmap is a visual plan of action that maps out the vision and direction of your product offering over time. The Product Owners use roadmaps to details the direction of the product, with the strategic goals, functionalities (features), the work required, the resources used on your product timeline. It is a strong communication tool for the product direction and progress that is available to internal and external stakeholders. Product Roadmaps are supposed to be updated regularly when changes occur (market, competition, technology).
The Product Vision is the very first step to take forward before starting working on any product. It represents the essence of the product and states where the product is headed and what the end state should be. A common analogy is made with the north star, always there and showing you the way. It might seem a classic but it will really give the Team a direction where every piece of work should answer yes to this question: will this help our product to achieve its vision? If not, then the piece of work (or feature) should go at the very end of your product backlog or even be removed.
The Product Vision Board uses pretty much the same layout as the business model canvas. It will help the Team to find the best Product Vision and make clear who are the end users, what are their needs, what is the product and how it should be built as well as setting business goals.
Product Vision Board
Project Chartering in Agile is lightweight compared to Waterfall projects and it usually consists in a single sheet stating the 5 W’s (Who? What? Where? When? Why?) and How as well as the authorization for the project. It is established by the whole Team in order to make information clear and drive the Team to success. The document is not final and is supposed to be dynamically updated whenever changes or new learnings occur to deliver a high quality product. It is often displayed in the Team room so the Team keeps focus on the objectives.