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.

Writing the Project Purpose

Have you been on a project where people just argue all the time about the features or the scope? Or a couple of the developers come up with software that contradict each other? Or no one seems to know what they are doing? Or maybe the team questions why this project is being done at all?

I have come across these kinds of things in a lot of projects. Let’s take a look at a real world example and show what you can do to fix these kind of problems.

No one knows what the project is about
====================================
One year into a 4 year project, I was invited to take over as Senior Business Analyst and Assistant Project Manager. The team had really been struggling with determining which requirements were part of the scope of this project and which were not. There were a lot of arguments going on between the Project Sponsor and the various stakeholders about what the project was supposed to deliver. The project should have been much further along after one year, but it kept being delayed while everyone tried to figure out what they were supposed to be doing.

Whenever I hear something like that, it is obvious to me that there is some problem with the project vision. Either it has not been shared with everyone, it is poorly described, or possibly some of the stakeholders disagree with it.

In this kind of situation, the first thing I want to look at is the project purpose or project vision to see if it is well written. Then I will interview key people in the project to see if they agree with the project purpose. I use this approach to discover what the problem is – a problem with the vision, with communication, or with lack of agreement.
….

Have you experienced something like that on your projects? I find it really frustrating to watch a team not making progress due to lack of direction and I just can not stop myself from trying to fix it.

Even though the project was already one year old, I went back to the original project documentation to discover what the project was supposed to be about. I also interviewed the Project Sponsor, Project Manager, and the key stakeholders of the project to discover what they thought the project was about.

I had the perfect excuse to do all that – I was new to the project so it was reasonable for me to ask what it was about.

I discovered that there were two, closely related projects, both of the vision documents were poorly written and confusing, and there was some of the same information describing the purpose and scope of each project. No wonder everyone was confused! Not only was the scope not clear on this project, but it was related to scope that was not clear on a second project!
….

In this situation where the two scopes were closely intertwined, I got permission from the Project Manager and Stakeholders to put both project visions together and rewrite them as if there were just one project. I analyzed the new vision, made sure it was clear and easy to understand, and got it approved by the Project Manager and the Stakeholders.

Once everyone understood the whole thing, they were able to divide the vision up into independent pieces. They actually redefined this as five new projects, each of which was well-defined and independent. That meant that instead of doing the projects one after the other, they could do all five at the same time.

We went from having one large confused team to having five small focused teams. There were no more arguments about which requirements were in scope or out of scope, no question about what was the most important thing to work on next, and the stakeholders were much more confident that they were getting what they needed.
….

What other approach might I have taken? Project 2 had not started yet, so what I had initially considered was just looking for related scope items and putting them all together in either project 1 or project 2, being careful to balance how much work was in each one based on their projected size.

In my particular situation this did not work for two reasons. First, there was a lot of overlap between the projects, so it was much easier to just put the whole set together to review. Second, the scope items were written so poorly that it was not clear which ones were related.

Before writing the project vision, I had to go back to the sponsor and stakeholders to find out what was intended by each scope item and rewrite a new set of scope items based on what was really meant. If the scope items had been well written, then it would have been easier to just move scope items between projects to remove dependencies and overlap.
….

In general, how do you fix problems with the project vision or project purpose? The basic approach is this:

  1. Review any written documentation
  2. Interview the Project Sponsor and key stakeholders
  3. Put together all the information you have learned and if there are any inconsistencies or areas that do not make sense, review the information with the Project Sponsor and together write something that does make sense.
  4. Analyze what you have written to be sure it is sensible and complete, do more research if you need to, rewrite the project vision if necessary, then verify it again with the Project Sponsor.
  5. I like to put the information into a formal statement or document so everyone gets the information the same way. This does not have to be a big document. I have worked on projects were 3 goal statements of one sentence each were enough to describe the project.
  6. Be sure to share this with everyone on the team. You will not remove the confusion unless everyone knows what the project is about.

Usually it is not much work to write a good project vision or project purpose. When it is a lot of work, that means it is even more important to do it right.

Why?

When it is a lot of work to write the project vision or purpose that is because there is a lot of uncertainty and misunderstanding. It can be a lot of work to resolve the issues and gain clarity.

Why is this important?

My project that was behind schedule after a year not only made up time, but finished early once everyone knew exactly what they were supposed to be delivering.

I see this every time that the project purpose, vision, or scope is poorly described – the team wastes a lot of time trying to figure out what they are supposed to be doing. If you spend a relatively small amount of time making sure the purpose of the project is clear, you save a lot of time for all the team.