|
Scrum is an agile framework
Roles:
Product backlog - list of stock that needs to get done from a business standpoint
This consists of all the features, functions, requirements, enhancements and fixes
These are broken down into user stories
PO creates the product backlog
PO knows what we are supposed to deliver and what business goals to deliver and business value
Prioritize - highest business value or highest business risk
Product backlog is the shield between team and business stakeholders.
Stakeholders - managers, legal and complience, users and many more
PO
Sprint:
1st thing to decide is how long sprint is going to be
Maximum of 4 weeks not more than that
Mostly common is 2 weeks
Sprint planning : PO to present product backlog so that highest priority items are picked by some conversation to check capacity and dependencies so that dependencies can be picked
Final commit from the team finalizes the sprint backlog
For the duration of the sprint a sprint backlog cannot be modified
Standup/daily scrum - every 24 hours
This is a commitment meeting, team member mentions, what was done yesterday, what is planned for today and any blockers(important as commitment might get impacted)
At the end of a sprint we get a potentially shippable product, i.e. sprint backlog is done
Sprint review: all stakeholders get a demo of the work done during the sprint
Get feedback from stakehjolders to team
We inspect the product
Points that come out of this meeting will goto product backlog
Retrospective meeting: important meeting for an agile coach.
We inspect the process, how we work together
Agile user stories drive a series of conversations about the desired functionality that help the development team collaborate to find the best customer value in the overall product development process.
Keep Focus on the User: a to-do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Blocks Transparency: User stories do not promote transparency. They are standalone and block clear vision.
Enables Collaboration: with the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Different Understandings: User stories have different meaning for different people in the team.
Drives Creative Solutions: stories encourage the team to think critically and creatively about how to best solve for an end goal.
Creates Momentum: with each passing story, the development team enjoys a small challenge and a small win, driving momentum.
Product Owners expressed their vision through small items called User Stories which are maintained in Product Backlog.
These User Stories are created, updated, maintained and prioritized as part of the Backlog Refinement.
Creating and writing user stories is a collaborative effort. We get the most benefits from user stories when they are created in open discussions between users, business professionals, developers, and other stake holders.
US is a simplified, high-level description of users requirements.
Don't necessarily too technical
Structure:
As a
I want
So that
Who, what and why
| Ex: | As a potential conference attendee |
|
| I want to be able to register for the conference online |
|
| So that registration is simple and paperless |
| Ex: | As a internet banking customer |
|
| I want to see a rolling balance for my everyday accounts |
|
| So that I can keep track of my spending after each transaction is applied |
US is more customer focused
Acceptance criteria:
Gives a detailed scope of a users requirements.
It helps clarifying what needs to be built
It helps in common understanding of US
It helps in knowing when US is complete
Example:
Create conference attendance form
An user can not submit without filling mandatiory fields
Information from the form is stored in regisration DB
Protection against spam is working
Payment can be made by creditcard or paypal
Acckoledgement email to be sent to attendee
Product backlog refinement:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items (e.g. User Stories) into smaller more precise items
User Personas
Creating user personas is key for a good US
Components of persona: name, picture, relavent charactoristic like age or income group
Common tasks
Userstory Mapping: it is a technique of organizing and prioritizing US
Vision --> goals --> activity --> tasks --> userstories
Story mapping is the effective way of creating a product backlog
Story mapping is the engaging activity beween stakeholdes scrum team and stakeholders
Map consists of user activities in horizontal axis,
Down the vertical axis it represents the details of the activity
Define vision --What, Who and why
Define highlevel steps, we call goals, ex: online shop: search product, view product, add it to cart, create account, fill personal info, fill payment details, cofirm order
Define common goals, we call activities ex group search product, view product and add to cart as "select product", create account, fill personal info as "manafge account" and fill payment details and confirm order as "buy product"
Create task from activities
Test it for gaps
Prioritize the colums of ,map like must have, should have, could have, wont have now
This is the starting point of product backlog
Based on story map we define iterations or releases, we try to get the minimum viable product that is MVP.
MVP is the part of first releaase/iteration
And based on priority so on
Keep the map updated
Story map is a living artifact and should be visible to whole team
The minimum viable product (MVP) is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
The value gained from Iterative Delivery with MVP includes:
Validated learning—Not necessarily a release, but enough progress to receive feedback early and often.
Just enough features—To gather validated learning about the direction of the product and the roadmap.
Minimized Risk and Spend—Defining, designing and delivering MVP is a critical aspect of Agile that allows the team to gather feedback quickly and change directions if needed.
User storyt components:
The Three C's capture the components of a User Story:
Card – Short, Quick description of the User Story.
Conversation – More about verbal conversation than written conversation. Discuss the card with others in the team and ask questions to clarify the details. The ultimate goal is to build the shared understanding.
Confirmation – Work towards the agreement on what to build through Acceptance Criteria.
A good user story should be:
Some Additional tips for writing Good User Stories.
Story splitting:
Needed for small enough to deliver within sprint
Easy to estimate
Slice vertically through the layers instead of horizontal
SPIDR approach to stpory splitting
Story vs Task
User Stories are estimated by the team and represent the collective team effort to deliver the associated user value. Whereas Tasks define the work that needs to be done to deliver the user story.
Acceptance criteria:
7 tips for Writing Acceptance Criteria (A/C)
It is a long established fact that a reader will be distracted by the readable content of a page when looking at its layout. The point of using Lorem Ipsum is that it has a more-or-less normal distribution of letters, as opposed to using 'Content here, content here'. Lorem Ipsum has been the industry's standard dummy text ever since.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's.
Created By Themexpose · Powered by Blogger
All rights reserved
