Posts Tagged ‘scrum’

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.

Lifecycle

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)?

What Time Is It In Your Project?

Marcin Niebudek,

One of our Clients brought our attention to one of the problems with time zones. You may not have noticed that in you tinyPM instance especially if you host tinyPM on your own. But they were using our hosted version where this problem turned out to be easier to spot.

So think for a second what does it mean when you say that your iteration start on Monday, July 4th?

Well at the first sight it may appear to be a strange question… at least if your whole team is co-located. But what if part of your team sits in London, part in New York and the rest in Sydney? What does the 4th of July means to you then?

Let’s assume we’re in London. In a face to face conversation you would probably mean July 4th around 8 am (which, in other words, means the start of your working day). Ok this will remain the 4th of July for New York (but around 3 am) and also 4th of July in Sydney (3 pm).

However when you use electronic tools and you enter dates without specifying time, this usually means 4th of July at midnight. Instantly your team members from New York will see it as 3rd of July (7 pm).

Of course handling different time zones is not a problem for the tool itself. The question is more general. How do you define your project dates in highly distributed environment? We would choose a single time zone for the project to be used for raw dates so that everybody knows that what we mean when we say July 4th, 2011.

This is also what we’re introducing in tinyPM 2.5.6. You may now define a project time zone. It will be presented next to all date fields which do not require time (like iteration start dates and release dates).

As usually you may find the list of all changes in tinyPM 2.5.6 at:
http://documentation.tinypm.com/display/DOC/Change+log

Are You Brave Enough to Let Go?

Marcin Niebudek,

Some time ago I wrote a post “Are You Brave Enough Not To Estimate Your Tasks“. Looks like we still need some bravery in another area… Task assignment.

Marcin Floryan posted a short statement on Twitter lately that if someone else is assigning your tasks it is not Scrum. I fully agreed with that, but just a few days after a question from one of our users came and it mentioned people being “overplanned”. The question wasn’t directly connected with task assignments but the word “overplanned” brought my attention.

Should I be “overplanned” or maybe “overcommitted”? Ok… You already know my answer, but think about it for a second.

Probably the most common path for many teams is to convert a PM into Scrum Master or alike. PM is usually used to assigning tasks to the team members. This is what she was doing for a couple of years. No we want her to surrender. Wouldn’t you be scared?

So why should you actually be brave enough to let go and let the team decide?

  • You already let the them discuss, estimate and plan how much they can do in the next iteration, did you? They will know what to do.
  • You will tend to assign same people for same kinds of tasks, but it does not help them to get a big picture and learn.
  • Why not leave the decision until the very last moment? Maybe others will finish their work earlier and will be able to take the task before the person assigned to it in the first place.
  • From the iteration/sprint perspective delivering done stories is more important than not who is doing what. Let the team find a way to make it best they can.
  • It’s like with code ownership. There is no my code and your code (right?). Same with stories or tasks that lead to creating that code.
  • There is that little chance that I may know better than you what I’m most capable of doing so please let me decide what I’ll do next to deliver what we promised.
  • You have lots of other things to do. There is this guy (they call him a Product Owner) waiting to slip through your doors ;-). Focus on facilitating, impediments and communication.

But not to leave you with an impression that self commitment is so glorious there is at least one thing that you need to be aware of at the beginning.

People not used to making a commitment will usually tend to chose the easiest task. After some time you will find that there is someone doing the dirty and hard work while others live their fantastic lives with their easy pieces.

This may happen if your team members are left alone with the tasks they work on. You should look for this kind of “bad smell” during retrospectives. But still taking the control back is not your best option. Instead try:

  • directing your team towards swarming on a single story together
  • some mentoring or pairing (maybe some of the team members have a difficulty with the system, technology or anything else)
  • working on better knowledge exchange

So are you brave enough to let go and not to assign the tasks to your team?

BTW. In tinyPM when you grab a task from pending state, it instantly becomes yours. This is a lot easier that to assign a task to somebody else (you need to go and edit the task). Now you know why :-)

The image for this post comes from a great site Pictofigo

Celebrating 10 Years of the Agile Manifesto!

Marcin Niebudek,

Alistair Cockburn has been organizing the event to celebrate the 10 years of Agile Manifesto. As a part of the event all the agile community members has been invited to answer three questions at the 10 Years of Agile website. Here are the three questions (copied from the Alistair’s website):

  1. What problems in software or product development have we solved (and therefore should not simply keep re-solving)?
  2. What problems are fundamentally unsolvable (so therefore we should not keep trying to “solve” them)?
  3. What problems can we sensibly address – problems that we can mitigate either with money, effort or innovation? (and therefore, these are the problems we should set our attention to, next.)

So let’s joins the dialog.

Problems solved

I’m not sure if the idea behind the Manifesto was to solve any particular problem except for restoring the balance between technology and business needs or expectations in the software development process. Was this solved? I think the move in the good direction has been made. The world moves faster now and still we developed the methods to keep up with software development. But the idea of being open to continuous changes and adapting to them makes the whole process  the never ending one.

So the Agile Manifesto made a ground for the movement that continues to evolve, bringing lots of new ideas to follow along with new problems.

Unsolvable problems

In one hand we want to improve, so even if some problems may seem unsolvable, we want to keep looking for better ways of solving them at least partially. Initial signatories of the Agile Manifesto wanted to restore the meaning of methodology in some way by pointing out that there are two sides that need to be addressed. However I think we’ve learned already that any single, unified and best for all way of doing thing is doomed to fail.

Some methods, frameworks, tools (call them as you like) as Scrum, Kanban started to fall in the trap of being perceived as a single “agile” solution to all the problems. This of course not true and wasn’t the intention of its creators either. So if I was to point the problem that we should not try to solve it would be the one to find “the” single agile way for all.

I look at agile as a catalog of practices from which I take different pieces to solve different problems in the given context. While the context changes many times, I need to choose again. Many people think that we need something more specific than the Manifesto, something codified, closed in the book of knowledge. I would rather like to keep the Manifesto open and general as it is.

The problems we should set our attention to

I think that many teams or organizations confused the discipline required to fulfill the principles behind the Manifesto with freedom. The catalog of tools and practices we can use has grown through those 10 years and today we are way better equipped to create a great software. But the problem that needs our attention is that so many teams tend not to use those tools. They are satisfied with the very shallow adoption of the ideas behind the “agile” movement.

Do we need to choose any specific problem to be solved next? Will it be agile and UX, or maybe agile for legacy code? As all in agile it should be context dependent. Different areas should be explored by different parts of agile community as they will face different problems. What would make agile die, would be to start thinking that there is nothing to improve anymore.

The image for this post comes from a great site Pictofigo

Advice on Starting With Agile

Marcin Niebudek,

Last week we got an e-mail from a user who found tinyPM and actually wanted to start using agile approach in his team. He asked for advice on where to start. I thought later on that I should actually post the advice here. So here it is…

There are tons of places that you can learn more about agile, but I think that there is this one perfect for starting quickly and getting the most ideas in one place. It’s a book by Henrik Kniberg called “Scrum and XP from the Trenches”:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

This short book will give you a perfect overview. In addition to that you should take a look at one unique blog about Visual Management:

http://www.xqa.com.ar/visualmanagement

And that brings me to an advice I need to give you at this point. I assume your team works in one place. So if you are starting with agile then read the book and build yourself a board like it’s described on Visual Management blog. Than try it out for a few weeks just by using cards, whiteboard and pens. Don’t touch any other tool unless you really need the project information stored in some electronic way.

The most important is for your team to feel the mechanics and the idea of these methods. They all depend a lot on direct communication and this is what your team needs to get used to in the first place. Then you can decide if you need a tool and this is a place where tinyPM will come very handy.

This is the shortest advice I can give. What advice can you give to a beginning agile adepts?

Back from AgileEE 2010

Marcin Niebudek,

A few days ago we came back from a great AgileEE 2010. It was a really good event which I personally find very inspiring. This is also why we’re extremely happy to be a small part of it as a bronze sponsor.

We posted a full list of speakers some time ago, but one photo stands for 1000 words, so see them all on one stage:

I’m sure everybody found something interesting in Kiev/Kyiv but just in case somebody wanted even more, we gave away some top agile books. So once again congratulations to the lucky ones and if you missed the conference – regret and make sure to be there next year.

In the meantime you can see most of the presentations at the conference site. Videos will also come soon.

We’ve taken some photos, which you can watch on our Flickr photo stream… Many thanks to all the people involved in the conference and other sponsors who made it possible.

Scrum vs. Kanban – How simple is that?

Marcin Niebudek,

This one should be short… When I think about Scrum vs. Kanban question (which is coming back like a boomerang over and over again) I really have just one single distinction in mind – time boxing vs. flow.

If you think about Scrum and Kanban as a process frameworks (and I do so) then you can find more similarities. They both show you how to organize the work flow, give simple tools (backlogs, kanban boards). They focus on team collaboration aspect of the process. They give you simple visual indicators (burndown charts, cumulative flow charts) to quickly spot problems as well as simple metrics to give you the basis for planning (velocity, cycle time).

What is different is that Scrum creates fixed time spans and concentrate some activities around those time boxes boundaries (planning, demos, retrospectives) while Kanban goes for the continuous flow, which usually means that the mentioned earlier activities will blur a bit and change their character to more ad-hoc (instead of Scrum’s meeting oriented) style. So the question you need to answer is actually which type of work flow fits better your organization and the character of your project(s).

Do you prefer cycle with boundaries when you can for example reach your stakeholders every two weeks? Or maybe you need a freedom to make your code base unstable for let’s say 1 week and get it back to deployable state after a sprint without a pressure that this will affect some other features that need to be shipped in the meantime? Scrum might be better here.

On the other hand if you don’t need strict boundaries and you prefer to manage things in ad-hoc meetings. If you can ship features one by one or can work on them independently. If each of those features brings enough value to be shipped alone when it’s ready, then you may find Scrum too limiting and go for Kanban. Maybe you don’t have direct access to your users, your users prefer smaller increments wand want to get updates whenever they are ready. Go Kanban.

As always, you should probably be choosing the best of those two worlds. The important thing to remember is that the framework is not enough. You need to have a high quality engineering practices behind it. And those practices may be the same no matter if you choose Scrum or Kanban.  So don’t spend too much time on it.

Shall I split my stories? Yes… I mean No!

Marcin Niebudek,

There is a story card on our wall estimated to 8 points. It’s so easy to tear it down and put two new 3- and 5-point cards instead of that big one. Cool, we can even move one of them to the next sprint. No, no, no…

But wait there is another story in our backlog. This one is big… No problem – lets split it into smaller functionalities. Yes… and yes!

So what’s the point? Is there a problem in splitting stories anyway? The short answer is “yes and no”. It’s because the problem lies not in splitting stories, but in the moment when we do it. There are usually to points in time when we think about dividing stories into smaller parts: release/sprint planning and the end of current sprint.

Plannig

This is the moment when we think about stories before we start implementing them. We choose what is possible to do within the planned period of time. We gather detailed information about stories that should be implemented first. This is the moment when we try to plan the work that fits into our capacity usually driven by some observations of our recent velocity and other factors.

At this point we may find some stories to be too big to fit into the sprint, but we realize that we can split them into smaller independent parts that are still able to bring value to our clients. We choose more valuable stories and leave the other for a better time or even get rid of them. This is where I say YES to splitting stories.

End of sprint

Next time we tend to think about splitting stories at the end of our sprints. This is caused by one reason – we just can’t finish the story by the end of the sprint. We thought we will, but (again) it wast one story too much. Actually we have it almost done. And this “almost done” tempts us to split the story, leave the finished part in the current sprint while moving just the unfinished chunk into the next timebox. Hurray! Our velocity, charts and metrics have been saved once again!

This is the moment what I say NO to splitting stories. Story should be either fully completed or moved to next sprint. And yes, velocity should drop this time. This is the only way to spot the problem in the long term. Ok, it’s not a problem when it happens once. But if we will break down stories at the end of the sprint regularly to keep our velocity untouched then we may miss the root problem (there will be no sign of it, except for a not so happy face of our PM/SM who needed to tell our client about yet another unfinished story).

The root problem of unfinished stories may be:

  • (most likely) wishful thinking – we keep thinking that we can do more this time and load our sprints with too much stories
  • too short iterations – the amount of features for the increment is good (less of them would not give any usable product) but we try to implement them in to short iterations, so maybe one week is to little and we should switch to two weeks
  • inaccurate estimations – if we have lots of unfinished stories every sprint this means that those stories tend to take more time than we thought and if it keeps happening then we should rather reestimate some of them and try better understand what they are about

So think about when you usually split your stories? Maybe it’s time to look deeper into your process.

tinyPM is going to AgileEE 2010!

Marcin Niebudek,

Once again we are going to Kiev for Agile Eastern Europe Conference which will run this Autumn (8-9th October). Last edition was a great event and we expect this year to be even better. It’s enough to look at the speakers lineup, to be sure that Agile Eastern Europe once again will become a really international event:

  • Mary POPPENDIECK (USA)
  • Henrik KNIBERG (Sweden)
  • Danko KOVATCH (Israel)
  • Marc LOFFLER (Germany)
  • Paul KLIPP (Poland)
  • Anda ABRAMOVICI & Sudhindra RAO (USA)
  • Robert DEMPSEY (USA)
  • Vasco DUARTE (Finland)
  • J.B. (Joe) RAINSBERGER (Canada)
  • Mack ADAMS (Canada/France)
  • Robin DYMOND (Canada/USA)
  • Yves HANOULLE (Belgium/France)
  • Monika KONIECZNY (Poland)
  • Andrea HECK & Tibor VIDA (Germany & Hungary)
  • Allan KELLY (UK)
  • Dr. Johannes MAINUSCH (Germany)
  • Sergey DMITRIEV (Norway)
  • Piotr ZOLNIEREK (Poland)
  • Sergei ANDRZEEVSKI (Russian Federation)
  • Andrea PROVAGLIO (Italy)
  • Pawel LIPINSKI (Poland)
  • Nikita FILLIPOV (Russian Federation)
  • Pavel GABRIEL (Belarus)
  • Artem SERDYUK (Ukraine)
  • Mikalai ALIMENKAU (Ukraine)
  • Timofey YEVGRASHYN (Ukraine)
  • Michael NORTON (USA)
  • Pawel BRODZINSKI (Poland)
  • Francois BACHMANN (Switzerland)
  • Jurgen APPELO (Netherlands)
  • Zsolt ZSUFFA (Hungary)
  • Gwyn MORFEY & Laurie YOUNG (UK)

We are proud to be once again to support the conference as a Bronze Sponsor, so if you use tinyPM, think about using it, want to talk about the tool, it’s capabilities and your need, then Kiev will definitely be a place where you can push us to the wall and ask all the hard questions.

If you haven’t decided yet to come, go on and REGISTER now!