Using Kanban to Organize Your Work

A lot of our Business Analysis work is very much the same from one project to another. Because we do the same tasks over and over, it can be useful to organize the work on a Kanban board.

A Kanban board is used to control the amount of work you have in progress at any particular point in time. It also shows the status of the work and how you have it prioritized. It is an excellent way to communicate with your manager and your team exactly what you are working on. At the same time, it is very simple to create, maintain, and review.

First describe a sequence of work. For example, if I were writing user stories for a project, once I have identified a set of user stories my sequence of work might look like this:

  1. Generate ideas
  2. Write the basic user story
  3. Write the acceptance criteria
  4. Review the user story with the product owner and set its priority
  5. Review the user story with the project team and get a size estimate
  6. Review the user story with a test professional and write scenarios
  7. Review the user story with a UI designer and create mockups

Each item on the list will become a column on my Kanban board.

Kanban1

Next, think about how much work in progress makes sense for each column. The idea column can probably be unlimited. How many ideas do you want to work on at the same time to write user stories for them? How many user stories do you want to work on at the same time to write acceptance criteria? What you will do with these numbers is control how many user stories you are working on at the same time. For the columns you want to limit, add that number to the column. I have big numbers for the Product Owner and Team reviews because those reviews are comparing a set of user stories to each other and so they work better with a large number of user stories. I have a small number from idea to user story because I have found that most of the time one idea turns into many user stories.

Kanban2

Finally, use the Kanban board. I have purchased 3-sided presentation boards from an office supply story and put the kanban labels across the top. Then I use sticky notes for the items in the column. I can set the presentation board on the end of my desk where I can see it and I can easily take it to meetings to share with others.

I start with generate ideas. I will use whatever techniques make sense to come up with a list of ideas of what to do in the project. I write each one on a sticky and put them on the board under generate ideas column.

Kanban3

Then I pick one that looks important and move it into the Write User Story column. This shows I am working on turning that idea into some number of user stories.

Kanban4

I write each user story on an index card styled sticky note. I can post them under the idea in the write user story column.

Kanban5

I will move no more than 5 of those user stories into the Write Acceptance Criteria column because that is the next thing to do and I will work on no more than 5 at a time. If there were more than 5 user stories, the rest wait in the previous column. They are on hold until I get the first 5 done. Also, I move fewer than 5 user stories. 5 is the maximum I set on the column.

Kanban6

Some people like to use red colored dots to put on items that are waiting, and sometimes make a note about what they are waiting for. This can be very useful when you are waiting for someone else to do something. You can show that your work is blocked and it is obvious to everyone.

Why Business Analysts should write User Stories for Agile teams

I have seen so many Agile teams struggle with requirements. They do not want big documents, they think they do not need a Business Analyst. In fact, they think they will just grab the Project Sponsor and have that person sit with the team to tell them what to do.

This has not been working out so well. Except in a small number of situations, it is not going to work out very well. The reasons have to do with the environment where Agile is designed to work. If your teams are not working in the right kind of environment, then the Agile team has to adapt how they work.

Let’s look at what that environment is supposed to be, where it breaks down, and what you as a Business Analyst can do to make it work better.

How Agile is Designed to Work
===========================

If you look closely at the Agile Manifesto, Extreme Programming, and Scrum they all are based on a particular work environment. If you can set up that specific work environment, then the practices work fairly well for the programmers. There are still some missing pieces and
possible problem areas for the business, which I will discuss at another time, but the development team is very effective.

What does that work environment look like? It is really pretty simple. You have:

* a team of 10 or fewer development professionals
* the team can do all the work; specifically they do not need to get a database person, security person, tester, or ops person, they do all the work themselves
* the team is seated together in the same physical location typically with lots of white boards available
* the team works the same days and hours
* the customer (Project Sponsor) sits full-time with the team
* the same team is typically kept together over a period of years

In this environment, user stories are written by the Project Sponsor. These user stories are placeholders for conversations that will occur between the development team and the Project Sponsor. They are not themselves requirements.

When the time comes to implement a user story, the team and Sponsor talk about the user story and how they will know it is complete. They will write up scenarios that describe what will happen. The developers estimate how much effort it will take to code the user story and decide if it will fit in the next iteration. If not, the user story will be split into smaller pieces. If it does fit and there is room for more work, the team repeats the process with the next user story.

Now the day comes to actually work on the user story. The team will get more details from the sponsor. They may white board a flow chart of the process, do some quick sketches of screen mockups, or make a list of business rules that need to be implemented. As the team works on writing the code they may go back to the whiteboard to discuss design issues or flow chart the flow through the code. Finally the code is complete, they test it, and release it.

….

It is easy to see that in this work environment, developing the requirements through conversations and white board sketches can work out (assuming the Project Sponsor actually knows the requirements).

But …. Does this description match what you see at work? Is the work environment described above anything like what you see at work?

My experience is that this kind of work environment is quite rare and in most companies it is not actually achievable overall. It would require a massive overhaul of the company, which would actually not be worth any benefits they might achieve. Instead, you might see this kind of work environment in small, well-defined areas of the company.

….

How is this model typically broken, and what are the consequences for requirements work?

These are the primary reasons the model breaks:
* The Project Sponsor does not have the time or the knowledge to sit with the development team and give them the requirements
* Your company is structured as silos and centers of excellence so there will be outside people, such as database, security, ops, and testing, that will be required to work with the team to complete all the work
* The team is distributed over distance and time – they cannot all work together at the same time
* There are a lot of users impacted by the work and all of them have to be considered when developing the requirements, not just what the Project Sponsor thinks needs to be done

What all of these things lead us to is the need for a requirements professional to elicit the requirements and document them in the best way to share that knowledge with people who are not physically present. For the vast majority of us, we need to document requirements because we cannot share them through conversation and white board sketches alone.

I do not mean to suggest that you have to produce big documents, nor do I think you should write all the requirements once at the start of the work effort.

….

There has been some fascinating research about the brain in recent years. What it tells us is that we as humans are genetically designed to respond to the present moment. We are not good at remembering things once the moment has passed, nor are we good at thinking of future impacts. Now clearly some people are good at those things, but most people are not.

Think about the last meeting you attended. If you did not take notes, how long did it take before you forgot what was discussed and what the action items were? Science tells us that as people leave the meeting, their brain drops a significant percentage of short term memory to leave room in short term memory for what they will be doing next.

This is why taking notes at a meeting is so important!

So even in an environment where everyone is together and having conversations, it is important to make notes of at least the decisions that were made and the action items that need to be addressed.

This is even more important when the team cannot sit together having conversations all day long. Any of the team members who are having discussions have to make notes to share with the rest of the team. Even if they can talk with the other people by overlapping work schedules, if they do not make notes for themselves, they will forget information that needs to be shared.

….

So what is the answer? I think we still need people who are trained in requirements elicitation, analysis, and a variety of ways to document information.

Here is an outline of an approach I have seen work really well:
1. The Business Analyst meets periodically with the person who is paying for the work. This might be a Project
Sponsor or a Product Manager.
2. The Business Analyst works with that person to determine the scope of the work – what are they paying for?
3. Based on that information, the Business Analyst determines what needs to be done to elicit the user stories. It might be working with the Project Sponsor or Product Manager. It might be working with various SME’s. It might be working directly with end users.
4. Before a new iteration of work, the Business Analyst works with the people who know the requirements (and often a testing professional) to develop the scenarios of a small number of user stories that will be implemented next.
5. This information is provided to the sponsor and the development team so they can determine what work will be done in the coming iteration.
6. The Business Analyst sits with the development team and determines what they need to know in terms of detailed requirements. The Business Analyst brings the right people to the team to discuss detailed requirements. In the situation where this is a lot of people, the Business Analyst may need to start work one iteration ahead of the development team, working on the detailed requirements to have them ready when the team is ready to implement them. In that case, the Business Analyst is the person that the team talks to in order to discover the requirements.
7. The Business Analyst creates just the right documentation to share the information with team members who are not local. This may be as simple as photographing sketches on a white board and posting the photos on the team’s online page.

The goal here is for the Business Analyst to work with the Project Sponsor ahead of the development team to be sure work is continuously streaming to the team. The idea is not to produce documents because some process said that every project has to have exactly those documents. Instead, you determine based on your particular situation what provides the most value.

….

It all starts with writing user stories and producing scenarios for them. Most likely the Project Sponsor will also want to collaborate with you to manage the user stories. And you, the Business Analyst, are the right person to determine how much and what kinds of documentation are needed to coordinate the work of your team.