Escolar Documentos
Profissional Documentos
Cultura Documentos
(Data taken from web searches using Google. Nothing magic here.
Personal notes inserted.)
User Stories
Example of User Story:
Given in the context of a user story card
conversation and confirmation.
Front of card: (see below) Card section describes the user story. The
Conversation section provides more information about the feature. Note the
feature (for a user to log in to a website) is small, so the story can be fairly well
described on a small card.
Whether or not these are right scenarios or cover all possible scenarios isnt really the
point.
The point is that the test cases for this feature are written on the back of the card in
support of the information about the feature and before the feature is developed.
Generally speaking, there is a very fine line between a requirements scenario and a test
case, so it isnt necessary to capture too much detail on the front of the card and clutter it
up. The card in its entirety represents the requirements for the feature; whether captured
in the Conversation section or the Confirmation section.
Even the description of the user story in the Card section carries some important
information. In this case, there is a pre-condition (the user must be registered) and a
post-condition (the user can access subscriber-only content). All of the card must be read
to get the whole story.
Importantly, the User Story is expressed in business language, and in a micro, more
easily understandable, information-packed format.
<different link>
Use the simplest tool. User stories are often written on index cards as you see in
Figure 2 (at least when your project team is co-located). Index cards are very easy
to work with and are therefore an inclusive modeling technique. (no rigorous
formatting conventions)
Remember non-functional requirements. Stories can be used to describe a
wide variety of requirements types. For example in Figure 1 the Students can
purchase parking passes online user story is a usage requirement similar to a use
case whereas the Transcripts will be available online via a standard browser is closer
to a technical requirement.
Indicate the estimated size. You can see in Figure 2 that it includes an estimate
for the effort to implement the user story. One way to estimate is to assign user
story points to each card, a relative indication of how long it will take a pair of
programmers to implement the story. The team then knows that if it currently
takes them on average 2.5 hours per point; therefore the user story in Figure 2 will
take around 10 hours to implement. (Clearly, we are talking XP. Estimating size is
critical here!)
Indicate the priority. Requirements, including defects identified as part of your
independent parallel testing activities or by your operations and support efforts, are
prioritized by your project stakeholders (or representatives thereof such as product
owners) and added to the stack in the appropriate place. (This is also critical here
for the management and scheduling of work effort)
You can easily maintain a stack of prioritized requirements by moving the cards
around in the stack as appropriate. You can see that the user story card includes an
indication of the priority; I often use a scale of one to ten with one being the highest
priority. Other prioritization approaches are possible priorities of High/Medium/Low
are often used instead of numbers and some people will even assign each card its
own unique priority order number (e.g. 344, 345, ).
You want to indicate the priority somehow in case you drop the deck of cards, or if
you're using more sophisticated electronic tooling. Pick a strategy that works well
for your team. You also see that the priority changed at some point in the past, this
is a normal thing, motivating the team to move the card to another point in the
stack. The implication is that your prioritization strategy needs to support this sort
of activity. My advice is to keep it simple.
In User Stories Applied Mike Cohn suggests a more formal approach to writing user
stories. He suggests the format:
As a (role) I want (something) so that (benefit).
For example, the user story of Figure 2 (above) could be rewritten as "As a Student I
want to purchase a parking pass so that I can drive to school", as you see in Figure
3. (below) My experience is that this approach helps you to think about who a
certain feature is built for and why, and as a result is the approach that I typically
prefer to take. The best advice that I can give is to try both and see which approach
works best for you.
2. Estimating. Developers are responsible for estimating the effort required to implement the
things which they will work on, including stories. The implication is that because you can only do
so much work in an iteration, the size of the work items (including stories), affect when those work
items will be addressed. Although you may fear that developers dont have the requisite
estimating skills, and this is often true at first, the fact is that it doesnt take long for people to get
pretty good at estimating when they know that theyre going to have to live up to those
estimates. If you've adopted the pair programming practice then a user story must be able to
be implemented by two people in a single iteration/sprint. Therefore if youre working in one week
iterations each user story must describe less than one week worth of work. Of course, if you
aren't taking a non-solo development approach such as pair programming the user story would
need to be implementable by a single person within a single iteration. Large stories, sometimes
called epics, would need to be broken up into smaller stories to meet this criteria.
5.
Figure 6. The AMDD lifecycle: Modeling activities throughout the life cycle of a project.
But when a user story is complete, it should contain a very similar amount of ceremony / documentation.
User Stories may be looked at as a low-tech format of index cards; if so, easy to see Use Cases as
bloated.
May look at the use case index (summary) as a user story.
Fundamental orientation.
Note: the Unified Process advocates the Analysts understand the problem domain explicitly and
elaborate this in scenarios, whereas the Agile community relies on real-time definition of scenarios by
solution domain developers in conversation with the customer, not the Analyst.
In the Unified Process, the Analysts act as facilitators to document requirements; in Agile, these
definitions are related to the customer.
Note user stories and scenarios also serve to drive testing. Developers in Agile define functional
acceptance tests. In the UP, scenarios and test cases are only separated by tracking state changes with
instance data.
Division of Labor
User Stories versus scenarios may be viewed as divisions of labor. Format
chosen must ultimately serve the same purpose. Why?
When co-location and real-time feedback (essential to an Agile XP
approach) is challenging, the persistence of more specific details is typically seen
as the approach for scale, and typically specificity arrives at something closer to the
UP Use Case approach. This notion of persistency is critically important in such
cases
A practical middle ground might be to treat scenarios as tests first and
foremost, with Analysts serving double duty as testers to remove the serialization
arising from overspecialization of roles.
This only occurs with teams that do not understand the innate progressive
elaboration aspect of the approach. Both Agile and the UP communicate and
embrace the notion that the written word, whether in document or other form, is
likely to be flawed with respect to key attributes, and therefore the paraphrasing
of stakeholder need is better facilitated through feedback from working software
demonstrations. (assumes the availability of the stakeholders)
Lean embraces either scenario concept for requirements engineering or the use of
higher-level business identifiable features to articulate customer need. But Lean
suggests that first and foremost the strategy should be to constrain the atomic unit
of scope to be what is minimal the notion of a Minimal-Marketable-Feature MMF.
This is due to the strategy of one-piece flow and the limiting of the WIP to optimize
throughput and minimize cycle time.