ISTQB FOUNDATION 4.0 | Tutorial 40 | Collaborative User Story Writing | Agile Method | CTFL Tutorial
Summary
TLDRThis tutorial delves into the ISTQB Foundation level certification, focusing on chapter 4.5, which covers collaboration-based test approaches within the Agile methodology. It emphasizes the importance of collaborative user story writing, involving stakeholders to ensure comprehensive and defect-oriented stories. The script explains the 3 C's of user stories: card, conversation, and confirmation, and stresses the significance of the INVEST technique for crafting independent, negotiable, valuable, estimable, small, and testable stories. The tutorial aims to guide teams in writing effective user stories that align with everyone's expectations and facilitate easier testing and development.
Takeaways
- đ The tutorial focuses on collaborative user story writing in the context of Agile methodologies, emphasizing the importance of stakeholder involvement in the process.
- đ„ The Product Owner (PO) is primarily responsible for writing user stories in Agile, but collaboration with all stakeholders is key for comprehensive and defect-oriented stories.
- đ Collaborative user story writing involves gathering business representatives, the development team, and the PO to ensure a complete and clear understanding of the story from everyone's perspective.
- đ The script introduces the '3 C's of user stories': Card, Conversation, and Confirmation, which represent the medium of description, the discussion around the story, and the acceptance criteria, respectively.
- đŻ The 'Card' is a physical or digital representation of the user story, the 'Conversation' explains the software's intended use, and 'Confirmation' refers to the clear acceptance criteria that define story completion.
- đ User stories should be detailed enough to guide test engineers, ensuring they have all the necessary information to perform testing.
- đ§âđŒ The common format for a user story includes a user profile, a goal to be accomplished, and the expected outcome, followed by acceptance criteria.
- đ€ Collaborative authorship can employ techniques like brainstorming and mind mapping to achieve a shared vision of the deliverable, considering business, development, and testing perspectives.
- đ The INVEST technique is highlighted as a guideline for writing good user stories, standing for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
- đ Each user story should be reviewed to ensure it meets the INVEST criteria, which helps in identifying clarity, value, and testability.
- đ The tutorial concludes by emphasizing the benefits of collaborative user story writing for organizations, such as resolving issues early and ensuring stories are easily achievable and testable.
Q & A
What is the main focus of the tutorial in the provided transcript?
-The tutorial focuses on collaborative user story writing in the context of Agile methodologies, specifically within the ISTQB Foundation level certification, discussing its importance and process.
What is the role of a Product Owner (PO) in Agile methodology?
-In Agile methodology, the Product Owner is responsible for writing user stories, ensuring they reflect the needs and perspectives of all stakeholders.
What are the three critical aspects of user stories referred to as the 3 C's?
-The 3 C's are Card, Conversation, and Confirmation. The Card is the medium describing the user story, Conversation explains how the software will be used, and Confirmation is the clear acceptance criteria.
What does the 'Card' in the 3 C's represent?
-The 'Card' represents the medium that describes a user story, which can be represented electronically on a digital board or physically on a sticky note.
Can you explain the 'Conversation' aspect of the 3 C's in user stories?
-The 'Conversation' aspect involves discussing the details of a particular story, including expectations and features, to understand how the software will be used to meet business needs.
What is meant by 'Confirmation' in the context of the 3 C's?
-'Confirmation' refers to the clear acceptance criteria that define what needs to be achieved for a user story to be considered complete.
What is the significance of involving different stakeholders in collaborative user story writing?
-Involving different stakeholders ensures that the user stories are comprehensive, addressing everyone's expectations, which can lead to better defect detection and more complete stories.
What is the common format for writing a user story?
-The common format for a user story is 'As a [role], I want [goal] so that [expected outcome]', which includes the user profile, the goal to be accomplished, and the resulting business value.
What does the INVEST acronym stand for in the context of good user stories?
-INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable, which are the criteria that a good user story should meet.
Why is it important for a user story to be 'testable' according to the INVEST criteria?
-A user story being 'testable' ensures that there is a clear understanding of how to verify whether the story's acceptance criteria have been met, guiding the test engineer in their testing process.
How does the collaborative authorship of user stories benefit the development and testing process?
-Collaborative authorship allows the team to obtain a shared vision of what should be delivered, taking into account business, development, and testing perspectives, which can lead to more efficient and effective development and testing.
Outlines
đ Agile Methodology and Collaborative User Story Writing
The first paragraph introduces the topic of collaborative user story writing within the Agile methodology. It emphasizes the importance of bringing together various stakeholders, including the product owner (PO), business representatives, and the development team, to create comprehensive user stories. The three critical aspects of user stories, known as the 3 C's (Card, Conversation, and Confirmation), are explained. The 'Card' represents the medium of the story, 'Conversation' details the functionality and expectations, and 'Confirmation' outlines the acceptance criteria. The paragraph also discusses the common format of user stories, involving a user profile, goal, expected outcome, and acceptance criteria, and highlights the INVEST technique for writing good user stories that are Independent, Negotiable, Valuable, Estimable, Small, and Testable.
đ€ Enhancing User Story Quality through Collaboration
The second paragraph delves deeper into the collaborative authorship of user stories, suggesting techniques like brainstorming and mind mapping to achieve a shared vision. It stresses the need for a user story to address everyone's expectations: what the customer wants, how the team will implement it, and the information required for testing. The paragraph also explains that a good user story should be reviewed to ensure it complies with the INVEST elements. It provides an example of a user story format, emphasizing the importance of detailing the login process, including fields, data sources, user IDs, and passwords, as well as specifying acceptance criteria such as password resets and login attempts. The summary concludes by reiterating the significance of collaborative user story writing in resolving issues and ensuring clarity and achievability in the development process.
Mindmap
Keywords
đĄISTQB Foundation Level Certification
đĄTest Analysis and Design
đĄCollaboration
đĄAgile Methodology
đĄProduct Owner (PO)
đĄUser Story
đĄ3 C's (Card, Conversation, Confirmation)
đĄAcceptance Criteria
đĄINVEST Technique
đĄSprint Planning
đĄTesting
Highlights
Introduction to ISTQB Foundation Level certification, Chapter 4 on Test Analysis and Design.
Focus on collaboration-based test approaches and Agile methodology.
Collaborative user story writing as a key technique in Agile.
The role of the Product Owner (PO) in writing user stories.
Importance of involving all stakeholders in user story writing.
Reviewing stories after they are written by the PO.
The 3 C's of user stories: Card, Conversation, and Confirmation.
Card as a medium to describe a user story.
Conversation to explain software usage and expectations.
Confirmation as clear acceptance criteria for user stories.
User stories representing valuable features to users or purchasers.
Common format of user stories involving a user profile, goal, and expected outcome.
Elaboration of user stories in descriptions and acceptance criteria.
Techniques like brainstorming and mind mapping for collaborative authorship.
User stories should address everyone's expectations: customer, development, and testing.
INVEST technique for writing good user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Reviewing user stories for compliance with INVEST elements.
The significance of collaborative user story writing in resolving issues and ensuring clarity in Agile methodologies.
Encouraging comments and queries for further learning and exploration.
Transcripts
Hello friends and greetings for the day
welcome back to another tutorial on
istqb Foundation level certification we
are in chapter 4 talking about test
analysis and design and today we are
getting started with the new segment
that is 4.5 collaboration based test
approaches and here we'll be talking
some of the important things from the
agile methodology that how we can work
together to identify the best test
cases
to get started of course we are talking
about the very first thing which is
collaborative user story writing of
course we understand that PO is someone
who is responsible in agile methodology
to write the user stories however we
always call it out as collaborative user
writing skill set or technique the
collaborative user story writing is all
about putting every single stakeholder
together in terms of discussing
Gathering up and and making sure that
the stories which are being written by
the PO that is product owner has
everything in it from everyone's
perspective however we can always review
a story at the end after it has been
written by the PO but that is subjected
to a small Rook right but if we gather
together including business
representative the development team and
the product owner together we would we
would result into writing a complete
story at a time itself and that's where
we do consider these as one of the good
techniques to be followed when it comes
to Agile methodologies in order to make
our stories complete getting it analyzed
then and there and also being more
defect detection oriented so let's see
what exactly the content is trying to
talk about when it comes to writing
collaborative user story a user story
certainly represents a feature that will
be valuable to either a user or
purchaser of the system or software user
stories have three critical aspects
called together as 3 C's concept now 3
C's here certainly stand for the card
conversation and Confirmation the card
stands for the medium which describes a
user story with all the information can
be represented electronically on a
digital board or can have a physical
board reflected by a sticky note as a
card also the next one conversation
which is conversation explains how the
software will be used which is a
description related to that particular
story that how are we trying to achieve
these things or what is the exact
expectation from the business on this
particular note and the third important
thing is confirmation which is a clear
acceptance Criterion now if I just
combine these three things together when
I say three CS every single story is
expected to have a visibility whenever
we work in a team so that it should be
represented with help of a card that
means there should be a physical or
digital card available which talks about
a particular work item in a significant
independent piece of paper or piece of
sheet or something like that right with
every single one liner story does comes
the details of it which is conversation
the conversation is more about what
exactly is the details of a particular
story what is the expectation what
features what functionality are we
looking forward to have when it comes to
a particular story and the third
important thing is that is when we come
to the confirmation which is the
acceptance criteria however sometime the
user stories can be very very detailed
or can have a very broad expectations
and outlines defined but given that the
set of acceptance criterias are written
we exactly know what is that we should
achieve at the end of the day as far as
acceptance criterias are met a story can
be declared as completed so sometime the
story can be very wide and people may
have multiple perceptions towards it
that what all should be implemented in
order to get it completed now given that
acceptance criterias are written it
would confine us to the point and we
will just be able to achieve the exact
acceptance criteria and then we will be
done with the story also to add here we
are also talking about the most common
format of a user story which is followed
worldwide is as a role which is
basically the user profile for example
as a user as a customer as a bank teller
or as a bank manager so involving the
Persona in the user story will always
give us a Clarity that that which user
profile is trying to do that work and
maybe the permissions and accesses and
lot of other things would be
automatically taken into account so the
format continues as as a role that is
user profile I want that is goal to be
accomplished so whatever you want to do
so that I can that is the expected
outcome which is resulting business
value for the role followed by the
acceptance criteria so in simple words I
can say this as the the template
basically reads it out as a story can be
written in format that as a user I want
to be able to login on an application so
that I can check my emails that's it so
now you have three all the three parts
that user is trying to login right and
then the subject or what you want to do
is login into the application and the
end outcome which is expected result is
of course I can check my emails that
means I should be able to see my emails
after that that and of course this on
line summary sometime may not be very
enough because login has to be
elaborated that what kind of fields we
will have from where will it be fetching
the data and what kind of user ID and
passwords are accepted and so on so we
will elaborate this in the description
and third thing of course is my
acceptance criteria which will determine
that whether a registered user is able
to log in or if we have any other you
know part of it which is like a user can
reset their password using forgot
password link as a part of it or they
can and just try three times to log in
with invalid dator so all that part can
be in the acceptance criteria which will
give us a clear picture that what is
that should be considered as a
completion of the story further to add
here of course collaborative authorship
of the user story can use techniques
such as brainstorming and mind mapping
the collaboration allows the team to
obtain a shared vision of what should be
delivered by taking into account three
perspective that is business development
and testing a user story should always
be written in a manner that IT addresses
everybody's expectation that is
including what the customer wants second
how the team will implement it that is
development and third it has all the
information and details required for the
test engineer to perform the testing
required for it so a story should not be
incomplete in any of these manner or any
of these elements it should be
fulfilling everyone's need right from
that single story also to add here when
good user story should be written as or
when we talk about the good user stories
as one of the example these are to be
following following the invest technique
now what is invest technique it stands
for independent negotiable valuable
estimable small and testable if a
stakeholder does not know how to test a
user story this may indicate that the
user story is not clear enough or that
is it does not reflect something
valuable to them or the state holder
just needs help in testing so indeed
very important that every single user
story has all the information related to
testing which guides a test engineer
that how they can use the data what kind
of steps to be performed and what is the
expected end goal of this story at the
same time when we talk about the
technique invest we want to remind you
that each story should be reviewed in
order to call it as a good story so of
course while reviewing you check for the
invest the invest here says independent
that means every single story should be
independent of other stories negotiable
which simply means that it should be
negotiated in terms of like if some
things are not being achievable then can
I go ahead and do something
alternatively for that so negotiable
that means we can go ahead and discuss
the scope of work on it then we talk
about valuable every single story should
add value to the overall project
completion that means there should be no
such story which does not contribute to
the success of product or completion of
the product that means that's not a
story at all right estimable uh the data
should be written in such a way that the
team can really understand the scope of
work and estimate the stories while
doing the Sprint planning and uh s
stands for a small of course small is
the work has to be as simple as possible
so that one person can take it up in a
particular Sprint and T certainly stands
for testable so it has to be testable
too so put together when you review for
these elements in a user story and make
sure sure that user story complies with
all these uh elements of invest then
that's what you call it as a good user
story so put together that completely
makes sense that how collaborative user
story writing could be seen as a great
technique to help organizations write
better stories at the same time analyze
them while they are writing together a
lot of issues will be already resolved
and at the same time we will be making
sure that we are writing something which
can be easily achieved without much of
the conversation or much of the
discussion questions or contradictions
related to that so that's all from this
particular tutorial team should you have
anything else feel free to comment below
I'm always there to address your queries
and answer them well till then keep
learning keep exploring keep
understanding the context thanks for
watching the video team and happy
[Music]
learning
Voir Plus de Vidéos Connexes
ISTQB FOUNDATION 4.0 | Tutorial 41 | Acceptance Criteria | Test Design Techniques | CTFL Tutorials
ISTQB FOUNDATION 4.0 | Tutorial 45 | Release and Iteration Planning | Test Management | CTFL
ISTQB FOUNDATION 4.0 | Tutorial 49 | Test Pyramid | Testing Quadrants | Test Management | CTFL
How to write good User Stories in Agile
ISTQB FOUNDATION 4.0 | Tutorial 22 | Sample Questions on Chapter 2 | ISTQB Foundation Mock Questions
ISTQB FOUNDATION 4.0 | Tutorial 55 | Defect Management | Defect Report Template | CTFL Tutorials
5.0 / 5 (0 votes)