A colleague on Twitter asked how do I break down my stories, acceptance criteria etc? As a reference point, "stories" refer to my use of User Stories on a task board or Kanban. It's a method of representing requirements or scope. In upcoming posts, I'll also write about acceptance criteria, size, blocks...
Let's say you have some work that needs to be completed or delivered (scope). Rather than the old fashioned shall statements to define the scope or requirement (system shall do this; system shall not do that)
, we're going to write a little self-contained story on an index card, post-it note, or something similar. When we're done, we're going to add the story card to our kanban board. Our user stories are written from the perspective of the user. In the case of the personal kanban, that's me. What you put in your user story may vary. But, for me, the stories have to be self-contained and they have to pass my "why" test. Though I don't write it in the user story or on the card, I map work I do back to higher level goals. If the work can't be mapped back to previously defined goals, I'm just wasting time. Let's try not to do that.
When writing a user story, this is the format I follow
As a <type of user>, I want <goal> so <reason>.
Here it is in action
As a blogger, I want to write a blog post about user stories, so people will understand how I use them.
Now I ask myself "why". What is my predefined goal that it maps back to?
Spend more time writing, speaking, and mentoring and less time directly managing or leading projects.
So, there you have it! Because I use both an electronic kanban and a physical one, I keep all of the details in the electronic version and use the physical one a visual reference. It is a constant reminder to myself and others of what I am committed to do, work in progress, work that is blocked, and work recently completed.
Have any question? Feel free to leave a comment.