Agile Software Development: Planning Flashcards
Agile planning and the agile manifesto
Responding to change over following a plan
The Agile approach to planning allows for change to be welcomed rather than avoided. We don’t adhere to a strict plan; rather, we align on the direction and intended outcomes and respond to feedback as we progress.
Customer collaboration over contract negotiations
We want to deliver value to the customer; therefore, we put more emphasis on building a valuable product rather than holding our customer hostage to requirements written in a contract.
What is meant by “To plan, think from the perspective of “The WHAT!” “?
What value does the customer need or require?
What is important to the customer?
What problem does the customer have?
What concerns the customer?
What is limiting the customer?
What is meant by “Just Enough, and Just in Time” in regards to agile planning
Planning is iterative and we don’t have to have detailed plans far out into the future because planning is done continuously. The development team focuses on completing the work for the current iteration before focusing on future iterations and they deliver the work they have completed incrementally. The approach to planning and implementing is “just enough” and “just in time”.
What does it mean when we say that Scope is fixed, but Resources and Time is flexible?
It means, that customers, get all the features they have asked, for no matter how much it cost, or how long it takes
What does it mean when we say that Time and Resources are fixed, but the scope is flexible?
It means we focus on delivering the most valuable features needed to make the product successful,, and reduce unnecessary or nice ot have requirements, rather than extending the time line or adding resource
Difference between Waterfall and agile
Requirements: Gathered upfront vs Gathered iteratively
Planning: All at once vs iteratively
Delivery: All at once vs iteratively
Time: Flexible vs fixed
Budget: Flexible vs fixed
Customer: Beginning & End VS Engaged throughout
Project Management Triangle of Constraints
Scope
Resources
Time
Difference between waterfall and Agile requirements
Waterfall requirements:
- The system shall, should …
Agile
- User stories
Roles in Agile planning
Product owner: Defines the “what” and sets priorities
- Requirements
- Product RoadMap
- Product Vision
Facilitator: Coach, Facilitate, negotiate between PO and TEAM
Team: Determines “HOW” and builds the solution
MVP
Minimum Viable Product (MVP) - is the minimum set of functionality that the product needs to have to be valuable for customers. Sometimes this called a Minimal Marketable Feature (MMF)..
How to prioritize user stories?
Only have the team focus on the user stories that will bring the highest near-term value
What is a product vision?
An aspirational statement, that helps everyone involved understand WHY we are building the product
Guides direction of the product
identifies the outcome of the product
Identifies target market
What is a “good” product vision statement?
A good product vision statement tells WHAT the product is attempting to achieve and WHO will benefit.
eg IKEA
To create a better everyday life, for the many people
eg Honest Tea
Honest Tea seeks to create and promote great-tasting, healthy,, organic beverages. We strive to grow our business with the same honesty and integrity we use to craft our recipes, with sustainability and great taste for all.
Product Roadmap
The roadmap lays out the approach to achieving the vision and is slightly more tactical; however, it is not too detailed. Product roadmaps can be constructed in a variety of ways using a variety of tools and there is no wrong way to craft a roadmap as long as it communicates the high-level plan for implementation of the product. The Product’s Vision helps the team construct the roadmap for the product.
How to write a user story
As a [role], I can [function/behaviour], so that [outcome].
3 Cs of user stories
Card - should fit on a single card
Conversation - should be written to drive conversation, should describe the “WHAT” not the “HOW”
Confirmation - confirm understanding and drives consensus amongst team and PO
Criteria for well-written user story
INVEST
Independent- User story can be implemented without dependency on other user stories, systems, or teams
Negotiable- User story can be rescoped or de-scope. Parts or pieces of the user story can be taken out or adjusted to make the work doable
Valuable- User story will provide value upon completion to the users
Estimatable- User story can be understood by the team and they can project the level of effort to complete the work
Small- User story can be completed within 1-3 days
Testable- User story can be clearly tested upon completion to ensure that it provides value and works as intended
Good acceptance criteria
Accompanies each user story
provides guidance and parameters for the function or need requested
Does not limit the team’s creativity
Does not tell the team “HOW” to do it
Acceptance Criteria
Acceptance Criteria are the details that elaborate on the specifics of what the customer or product owner will accept to accomplish the user story.
Tasks
Tasks, derived from user stories and acceptance criteria, that the development team lists out to complete. Tasks are the individual steps to implement the user story.
EPICS
Epic - A large user story that needs to be broken down to be implemented
How teams, PO’s and customers communicate
Features
Feature - Functionality or sets of functionality that provide users of a product with specific capabilities
How PO’s and customers communicate
User Stories
User Story - The description of functionality that a user or role needs that is written in a story format. User stories are written from the perspective of the user or role requesting the functionality
How Team and PO’s communicate
Which other tools can be used to help the team or customer better understand the requirements
Wireframes
Prototypes
Diagrams
The development team has been working on the user stories but they don’t understand why they are building the features they are building. They also don’t understand how the work they are doing aligns with the product’s strategy. What should they look at to get a better understanding?
Vision statement
When faced with multiple stakeholders, how could you develop a product vision statement
- Identify key stakeholders
- Help them express their view independently
- Get them to discuss and understand each other’s views
- Bring together the most important parts to create the shared vision.
