Posts Tagged ‘user stories’

Today about Iteration big and small

Marcin Niebudek,

We have already had User Story as most popular tool. But this is not the end. Today about Iterations: the small and big ones, these that are completed and those that are never stopped.

Yes We Can

Iteration is a period of 1 to 4 weeks. During this time Customer needs to decide what is the most important at this moment. 4 weeks is also called the Sprint but we prefer Iteration as it’s stronger option.

Iteration is not only about programming but also about tests and more. Actually tests are run before the programming phase.

We also have to mention about infinite period. In this case Iteration is one, only User Story has to be completed in some period of time and then disappears. In this place another User Story appears. Customer tells about that User Story and if it’s good we start with the new one.

And what do you think about this?

What is a User Story and Why Should I Care?

Marcin Niebudek,

User Story is a most widely used tool in many Agile methods. Sooner or later you will need to work on some of them or you will need to write a few yourself. At first glance the whole idea may look strange. All those agilists tell you about index cards, about putting them on the wall. They organize them into themes, create some strange maps, call some of them epics, etc.

What is a User Story?

Let’s start from the beginning. User story describes part of your requirements or part of whatever you are trying to achieve in general. In software development we got used to some template (but this is just an example):

“As a [user/role] I want a system to have [some functionality] so that I can achieve [some goal].”

For example:

“As a blog author (my role) I want to be able to create categories for my posts (functionality), so that I can organize all the posts that I write into related topics for better reading (the goal / why I need this).”

But also:

“As a doctor (role) I need to have access to a patients health records and history before the patient comes to a hospital for a scheduled visit (process improvement) so that I can prepare a plan and book some procedures and a patient stay shorter (the goal / why I need this)”

The goal

Actually a template is not so important and if you like different one, then just use it. The most important is a goal part. A user story should bring some value, otherwise why would you want to do it? When writing a story always think about presenting it to a person mentioned in a story (doing a demo)? How would you show that the goal was achieved? If answering this question is a problem, then you should probably rethink your story.

Big and small stories

We usually tell that a story should fit into an index card or a post-it note. The point is not to put too much detail in a single story, but it’s not a level of detail that matters. It’s about story complexity and the expected amount of work required to be done. You should be able to complete a story in some reasonable time. If you work iteratively, then your story should fit into iteration. If you measure cycle time, then the best amount of work put in a single story would fit more or less in that time frame.

Does it mean a story cannot be bigger. No, not at all. Sometimes you will have just a raw idea about what needs to be done. Your story may initially be just called “Customer service improvement”. We will call it an epic. This story will get more details over time. You will split it into smaller stories that can actually be implemented.


A story have its own lifecycle. It lands in your backlog as an epic, then it gets some details and becomes a set of stories that we can call ready. This is time to start implementing them. They will now go from to do to completed through some various states (depending on your process). There is one more important step…

A story needs to be accepted. This is when you present the outcomes of your work. You will verify if that story meets the set goal. If not, then it will require some more work (which means it will get rejected), otherwise it’s done.

Themes and story mapping

If you are dealing with a complex product or service then you may have a lot of stories to deal with. Having a large backlog is in my opinion a bad idea in general (and I will write a bout it in a few days) but if you do have such a backlog then it’s a good idea to group stories in themes. Themes will usually evolve from groups of epics.

There is also a very useful practice called story mapping. It’s out of scope of this post and I encourage you to read more about it at Jeff Patton’s blog.

What to do next?

So let’s get back to the main question. Why should you care about stories?

My answer is because they are a powerful tool. I would encourage you to think about user stories even if you do not intend to dive into Agile world. They will give you a good perspective and will help you focus on the right things. If you want to learn more about effectively using stories there is a book I especially like. It’s “User Stories Applied” by Mike Cohn.

What the Story Card Color is Telling You?

Marcin Niebudek,

We always thought about color-coding story cards as a very good way to indicate different types of user stories. The most popular was of course to use the red color to indicate bugs. But also green played well for indicating some general ideas to verify or think about (expressed in terms of a user story on the board).

Lately we’ve received a graph from Tatham Oddie, one of tinyPM users, who thought that we may find it interesting to see how they used card colors in tinyPM. A few minutes later I was asking Tatham if we may share it with others and here it is.

And this is what Tatham says about it:

“We’re building a guided case management system. The team in the organisation who determine all the guidance are the Practice Development Centre, or PDC. Early in a user story’s lifecycle, it’ll bounce back and forth between our PO and the PDC team. PDC don’t have access to tinyPM, but the PO uses colours to track which stories are dependent upon PDC outcomes.

Once the PO and PDC are both happy, it progresses to blue which indicates that the user story is of sufficient stability for the dev team to raise any of our own queries, then size it.”

So what they actually did is that they create a color-coded workflow bringing user story to a READY state. And how do you use card colors on your board (not necessarily in tinyPM)?

Dude Where Is My Feature?

Marcin Niebudek,

Looks like we will start a new series because today again I would like to write about something that relates to the question received from one of our users. Let’s take a look at story acceptance process.

So there comes the day when you demo your product and a product owner shall accept stories after just closing iteration. We’ve implemented a quite simple and intuitive way of accepting or rejecting stories in tinyPM.

Basically, as a Product Owner, you can do two things for each story that has all its tasks completed:

  1. Accept the story – which simply marks it as accepted.
  2. Reject the story – which will also mark the story as rejected, but in addition to that you need to provide a reason for rejecting the story. This description will become a new task within the rejected story.

And here the story begins… What should happen now with such a story? Due to added task the rejected story goes back to “in progress” state because not all tasks has been completed. In other words, by rejecting the story we add more work to be done to finish story correctly.

But it’s the end of the sprint. This leaves basically two choices (well maybe three but the 3rd one is a bit unlikely):

  1. You move the whole story to the next iteration. Yes, sorry, it’s not done done and you loose velocity.
  2. You leave the story accepted, create another story like “Minor/non-blocking bugs from previous iteration” and move the task there. This way the story will have all tasks finished again and it’s possible to leave it accepted where it is now (you may add a comment to the story to give at least some trace of the bug there).

But even if the 2nd solution may sound tempting, I would call it a project smell in the long run because you may find yourself moving many tasks this way. It will result in violating Definition of Done and cheating on velocity which will most likely stay intact. I wrote about it once in “Shall I Split My Stories? Yes… I Mean No!”

I’ve mentioned the 3rd option, so here it is (but rather unlikely).  If it’s really a minor bug and you have still some time in the iteration, you may fix it (for example the same day) and still get the story accepted.

I would rather opt for the 1st solution as it may actually reveal the root problem if you will notice loosing velocity in such a way a few times more. Maybe you overcommit in the first place and then need to cut corners. Or maybe you should work on improving communication with your PO during the sprint to learn what may be wrong with your stories earlier. This way when it comes to the final demo most of the stories will get accepted as they meet the PO’s expectations better.

And which way do you choose most of the time?