Posts Tagged ‘opinion’

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.

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:

Expectations

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 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…

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?

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.