К основному контенту

User Stories: a mindmap and a quick overview

Below is a simple mindmap for "Stories"

It gives a quick overview of the user story "concept" and how we used
it in our project. In short we:

Write small, deliverable, user stories ( 3-5 days )
Store them in Jira and on sticky notes
Include in each story a brief summary that highlights what it does,
why its valuable, and several tests
Evolve them from simple reminders, to placeholders for our
understanding, and finally an agreement on when we are "done".

This gives us some advantages:

(1) We are able to be more flexible since the details can be fleshed
out when the time is right
(2) We are able to collaborate and focus on verbal communication
instead of passing on written documents

I'll elaborate a bit on of each of these points.

Writing small, deliverable stories

Finding the "right" size for your stories is somewhat tricky. Since
people have very differnet ways of specifing "size" you are likely to
have to experiment and go with what fits your team. For us, it seems
that we have had most success with stories that a single developer
would use 3-5 days on.

Storing in Jira and on sticky notes

The simplest storage method is just to write things on a sticky note
and place it on your wall. It's quick, easy, and visible. Using some
software to store them can also be quite useful. In an offshore
situation that kind of becomes necessary.

Even if you use some software place to store your stories, I have
found that it's good to keep writing those sticky notes and getting
them up on the wall. This way the stories are always visible to
everybody, and there is also just a "feel good" factor in "physically"
taking them down when you are done.

Include in each story a brief summary that highlights what it does,
why its valuable, and several tests

One of the more tricky things is finding out how much to put into a
story. Again, this depends on how your team feels about it.
Before we started using stories we have some small "specifications".
These where typically a few pages with some text and screenshots.
Switching to user stories can be a slight shock to the system. The
most common question I got was, "Where are the details?".
Well, we do actually have a lot of "details" in our stories. These are
represented by the tests and an a GUI prototype. User stories are not
about masking out details. In order to deliver the story you need to
flesh out these details ( as it becomes necessary ), and in most cases
write them down as tests. In my world, the difference between user
stories, and some kind of "specification" is not really that big. It's
how you get there that counts. It's the collaborative, lightweight
"process" of going from an idea to an understanding of when a story is

In my experience, one of the biggest challenges is to make sure we
actually do the things necessary to make stories work. If you don't
discuss them properly, sincerly write down the tests, and collaborate
during them whole process, then your stories become more of a problem
than a solution.

Evolve them from simple reminders, to placeholders for our
understanding, and finally an understanding of when we are "done"
The reason why stories work is that they are flexible and demand that
you collaborate. A story starts out just as a simple reminder of a
discussion with the client. It evolves as you discuss it with other
people in the team, and you flesh out some details. In the end it
guides you towards aswering that simple question, "when are we

Ragnar Birgisson, Mar 07, for Agile-Ukraine Google group,
the discussion thread


Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations

Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.

Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Календарь тренингов по Agile

Наши партнёры по тренингам: