User Stories Flashcards
set of criteria used to determine quality of user story
INVEST
Independent
Negotiable
Valuable
Estimable
Small
Testible
acceptance criteria
scenarios to pass user story with pass/fail
does not focus on a solution, tests the intent of a story. include the WHAT not the HOW.
ex:
GOOD: sales rep should be able to create a pdf for the sales order
sales rep should be able to create a pdf for the sales order by clicking a button - THIS IS A SOLUTION BAD!!!
definition of done
the product was built right.
Outlines everything the team must do to complete project
scrum values
focus
courage
openness
commitment
respect
scrum lead
manage team’s delivery process
remove blockers
product owner
defines, approves, and assigns work
prioritizes product backlog
facilitates communication between stakeholders, team members, and scrum lead
works with customers to define features
product backlog
all the tasks needed to complete project and get it done
sprint backlog
every 2 weeks, prioritized items from product backlog move to sprint backlog to be completed
types of scrum meetings
planning meetings - make sure aligned on final outcome
– release planning every 4 months
– backlog refinement (what is going in the future)
– sprint planning (what are we going to do in the next sprint)
– daily stand up
inspect and adapt meetings - improve the process, take learnings and apply to upcoming sprint
- retrospective (what did we do right / wrong in the last sprint)
- sprint demo (present what we did)
who should be involved in a user story workshop?
members of the project team
what should acceptance criteria state?
Intent, not a solution
what is INVEST in user stories?
Independent: User stories should be independent and not overlapping in concept with another user story.
Negotiable: A user story is not a contract. A story is an invitation to a conversation. It captures the essence, not the details.
Valuable: The user story needs to be useful to the end user. If a story does not have value, it should not be created.
Estimatable: A successful user story’s timeline can be estimated. An exact estimate is not required, but just enough to help prioritize and schedule the story’s development/implementation.
Small: Most effective user stories are small. Smaller user stories tend to get more accurate timeline estimates. Remember, the details can be elaborated through conversations.
Testable: A good user story is testable. For a successful story, anyone on the project team can look at the user story and say, “Yes, I understand this user story so well that I can write acceptance criteria for it.”
common user story mistakes
project team didn’t hold a user story workshop, and now have different ideas of user stories
there is no ‘who’
the ‘why’ is too specific and feature focused. Should be generic!
Acceptance criteria is too vague
user story was assigned to implementation team without discussion
three keys of DevOps
flow, feedback, continuous improvement
what is a value stream?
invisible, shows the sequence of processes needed to give value - high level steps with metrics on time, value added, and quality. Can identify waste
