coursera - SaaS - 4.2 - SMART User Stories

https://www.coursera.org/

Okay, let's, let's go back. Alright, so
the user stories go on these 3x5 cards.

Well, what's a good user story versus a
bad user story? Well, our module loves

acronyms and so this, to help you remember
what they are and this is, Acronym Smart

is to help you figure out what's a good
versus bad user story. So smart is. We

wanna have these five adjectives apply to
your stories. They're specific,

measurable, achievable, that is can be
done within one of these agile

alliterations, relevant, this is supposed
to be business relevant. And so you often

as a programmer will say well this will be
a cool feature but the question is why

does it matter? And it usually doesn't
matter to the business. And time box is a

strange word to know when you ran out of
time, so it's a limit. So let's just go

over those. Specific and measurable each
scenario should be testable the supplies,

that there's a, known good input and
expected result. And if you can't figure

out what the. Specific input, and the
results then it's not. So here's an

example of something. That's a, a nice
thing to say, but it's not measurable,

right? It's not testable. It should be
user friendly, right? Well sure it should

be user friendly. I could imagine someone
writing that down but how do you test

that, right. Do, do you human subject
experience with 100 people and then they

check a box is it friendly or not. No,
that's not very useful. We need something

more specific. So that has led to this,
this adjectives approach that you'll see

that we use in specifying the steps of a
scenario. [inaudible] commands given when

and then. So given some specific. Starting
condition when I do X, that's one of the

more specific things to happen so. What we
are looking for is specific inputs and

specific results so that we can test it.
So it's got to be testable. Specific.

Alright, A stands for achievable. What are
you going to do if you have a feature you

want and you can't evaluate, implement it
in a single iteration? Because the whole

idea of Agile, is it's always working,
right. You don't want at the end of an

iteration an incomplete code. And the way
for us to help figure out [inaudible]

test, for you to learn on your own how
long it takes you to do something is to

actually to keep track of what your team
does. So what you, the model is simply

that each of your teams when you look at
the stories, you try and evaluate how hard

this is. We recommend that you start off
with a three point scale saying whether

it's basically easy, medium or hard and
then you look at these stories and assign

it a value. And then you calculate the
velocity of your team which is simply how

many points you complete. So if you, if
you assign three. Stories each three

points and you [inaudible] completed
integration then your, your team did nine

points and you accumulate the long term
average which improve both of your ability

to estimate difficulty, and how fast your
team gets work done and that's how you

calculate your, velocity. And then you
[inaudible] to figure out how long things

take. So you've done some user stories.
Your team takes this long to do them.

You've got a whole bunch of useless
stories in the backlog. You've estimated

how many points they are. You, you know,
you divide the velocity into the remaining

points. That gives you how long it's gonna
take to get things done. So, why, that's a

really simple common sense idea. Why is
that useful? Since you're talking to the

stake holder, the costumers every week,
you can tell them wow, I think, we, you

know, that's a great feature, if you want
us to do this other stories we won't be

able to get to that for two months. And
then that is, starts the feedback to

decide well maybe you wanna change
priorities. So, achievable time box. How

about the next, so S, so that was smart,
S, specific and measurable, achievable, R

is relevant. So it's supposed to have a
business value in developing this

software. So here's examples of them. It's
can protect revenue or increase, you know,

we usually think of an increased revenue,
but it could protect it as well as

increase it. It could reduce costs. It
could increase the value of the brand so

that people are going to like it better.
Make the product stand out. Provide more

value to the costumers and there's an
example of a URL that you can go there.

Now something that we've heard about that
can be useful to figure out. The business

relevance is what's called the five Why's
and actually I heard someone call it the,

the twelve Why's. But basically, the deep
insight is you keep asking why. So let's

do the Facebook for instance for managers.
So I'm a box office manager, Armando's

has, works with A theater in Alameda, and
he's the, their IT guru. So why would you

want to add a patron's Facebook friends?
So, he's, the box office manager

[inaudible] kind of induced the patron to
buy a ticket. All right? So then you'd

ask, well, why? Why do you wanna do that?
Well, I want to sell more tickets. Well,

why do you want to sell more tickets?
Well, so we can get more money for the

theater. Why do you want to get money for
the theater? Well, the theater just barely

breaks even right now, and you know, we
need more money. And, why do you want to

do that. So, I can have a job. Okay.
[laugh]. So, surprisingly, just by asking

simply you could have a dummy program, you
just keep asking why, it helps you sharpen

your answers so you get down what the real
development reason is. So that simple

mechanism helps you figure out. What it is
that the business value other that it just

sounds like a good thing to do?