Archive for the ‘Agile Practices’ Category

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.

Agility starts with Expectations

Marcin Niebudek,

When we first started creating tinyPM, we wanted to build a tool that will help us do some often repeated things, that will help us structure our actions and make it all visible to our clients. We did not create any user’s guide. We assumed that everyone that will start using tinyPM will find elements familiar to agile environment and the only thing we need to do is to make them easy to use.

Why Are We Here

We assumed that a user of agile tool will know what to do with it. But the time passed and agile way of working got into mainstream. Now we often get questions “Where is the user’s guide?” or “I signed up, followed the first steps, but what do I do next?”. Finally “We want to start working agile way and a friend told me to take a look at your tool”. This one actually made me think about this post.

So many people want to be agile these days. That’s great as agility offers great ideas, but the first steps those people take go down to finding a tool that will… Hmm… I think “that will guide them” is what they actually are looking for. If you are such person or if you ever be asked to recommend a tool, please, first think about:


If you think about Agile, I’ll give a short recipe or checklist that I would like you to follow.

STEP 0 – Agile Manifesto

This is an ancient paper once created to remind the values and principles that make us all want to be agile. READ IT! I really do mean it. Read the manifesto, but what is more important read the principles. We’ve done a terrible thing once and read only a few first pages of Winston Royce’s Waterfall paper not paying attention to the rest of the document. Please do read the “second page” of Agile Manifesto.

STEP 1 – Ask yourself some questions

  1. What will change after I become more agile? What change do you expect? How your situation will then differ from what you are dealing with right now?
  2. Why am I doing this? What is wrong right now? What areas do you expect to fix?
  3. If you could remove one of your current problems, which one would it be?
  4. Do you see some agile principles that you could follow to remove that single problem?

This will set your expectations. This will help you focus on the right things. Being agile is useless unless you have some expectations towards your current process.

STEP 2 – Experiment

Take the most painful problem and try to find agile solutions or at least try to find out what Agile methods are offering to solve that problem. But start with a problem and expected outcome. You will quickly find out that your first steps lead to a team’s room or to a chat by the coffe machine, not to a web sign-up form. That will come later, probably somewhere around STEP 20 :-)

If you don’t know what to do with an agile web tool, then you’ve probably tried to skip some steps. Unfortunately this will rather slow you down instead of making you more agile and we really want you to succeed!

Go talk with you team mates.

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 Criteria Do You Use When Choosing Agile Tool?

Marcin Niebudek,

This question has been asked today on LinkedIn Q&A. I wanted to post an answer there in the first moment, but then I though that those Q&A’s tend to fade out very quickly and maybe answer to that question deserves some more attention.

Different criteria in different contexts

Well, the question was asked from a perspective of a tools reviewer. This in fact makes it more interesting. Normally I would say just choose the criteria that match your team or organization needs. But here its different.

What one should do to review a few dozens of tools on the market? Is it possible having a “generic” reader/tool user in mind? Is there someone like “generic” tool user seeking for an advice in choosing the agile tool? Sure there isn’t.

There are many agile flavors. Even if we choose to call some of them “methods” which would suggest they consist of more strict rules to follow – they don’t. Teams or the whole organizations choose different practices to be applied. Even same practices or ideas are applied in different ways.

Tools usually will do better in some aspects and stay behind in others. This is natural effect of different influences and experience their creators have. So each of those organizations needs a different set of criteria.

So let’s turn things upside down

What if the reviewer tried something different and yet something we perfectly know (at least in agile world)? How about taking the tool under the review and finding a set of user personas that this tool is going to be best for? How about creating something similar to a persona but for the organization? Maybe some kind of imaginary company profile that the tool would fit the most.

What goals the tool will satisfy? Who may have such goals (in a software company for instance)?

Maybe it will be Jack the Geeky Developer who works in a 5 people team and have a remote Product Owner. Jack works on 3 projects at the same time (two of them are in the maintenance mode) and wants his current assignments and commitments to be easily accessible for him. He may be able to switch between them easily and the Tool X will do the best for him as it’s good in organizing the work in many projects.

The Tool will be also good for Alice – the Scrum Master of a few teams in her organization. Alice shares her time between those teams and needs to be up to date with each one instantly. Which would be satisfied by features A and B.

But Bob, who likes extensive reports full of charts and KPIs, may be disappointed with the Tool X which provides only basic data exports. There are more data hidden in the Tool’s API but Bob will not even care to dig into this. He has simply no time for that.

Is the the organization where Jack, Alice and Bob work similar to yours? Then this may be a good tool for you, but only when you are able to convince Bob that the information he will get is enough to run the company.

I’d love to see some reviews like this. I think it might do more good than assigning some points in various categories and publishing the overall score. This kind of criteria based evaluation can be done only internally where there is one organization and many tools.

But when you are on the other side and try to review the tool (of any kind), then no set of criteria will ever be relevant to a particular reader (or at least to just a few of them). On the other hand reader may see herself in one of the personas you will try to describe. If so, then maybe the tool is right for her. Otherwise she will know instantly that this is not her Bob and Alice.

How does that sound to you? Wouldn’t that help you more in choosing the tool (or at least choosing it for further evaluation)? Just an idea…

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?

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

How to Deal With Bugs in tinyPM?

Marcin Niebudek,

We offen get this qustion, so it may be a good idea to quickly answer it here as there are at least 3 different approaches possible.

Task in the original story

You can put a bug as a task in the original story. We use this approach when bug is found within the same iteration where the story is developed. We simply add a task and fix it in the same iteration. Bug found in the iteration must be fixed in the same iteration as the definition of done for stories contains “no known bugs”.

Separate story card

You can put a bug as as a separate story (usually as a red card). We do it when bug is found later, after the iteration where the original story was completed or if the found bug is more general and does not belong to any particular story.

Sometimes we create just a single aggregate story like “Bugfixing” and place all production bugs there as task. If the bug is serious and requires some more effort then usually has it’s own story with more task that need to be done in order to fix the bug. Bug stories are estimated as “0″ which means they have to be done but do not add up for velocity (so are treated as debt).

To estimate bugs or not is a whole different story, but we personally do not estimate them.


Finally you may use tinyPM’s sandbox as a place to gather bugs. There you can first check if they really are bugs or investigate them further before they will become stories. Some of them will be rejected and will never reach your backlog, some other will become stories.

Sandbox also allows connecting with JIRA bugtracker, so if you need a fully featured bugtracker and your bug tracking process is more complicated then sandbox connectors may be the way to go. This way you will keep the bugs in the external system and buffer them through sandbox in tinyPM.

Most of the time we use a mix of tasks and story cards while using sandbox as a buffer for ideas from our UserVoice forum.

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”:

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:

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?