Posted by tac_admin, November 18, 2011

Sticky Note Parties – Been to One?

Have you ever been to a sticky note party? It’s not the kind of party I get excited about attending…. 🙂

This is an exercise you’ll see being done as part of software project planning.

If you have a large project that will take multiple years to complete, you may only focus on planning the analysis and high levl design and then have another planning session at the end of high level design to plan the low-level design, construction, testing, and deployment phases.

Project planning sessions that use the sticky note exercise – this is where the party happens. Here’s an outline of what happens in the two-day session:

  • The core project team gets together in a conference room (face-t0-face is best for these meetings)
  • Someone from the project management office (PMO) is there with Project open on their laptop ready to capture info
  • Another person from the PMO is at the front of the room with a long piece of paper taped to the wall and a pack of sticky notes in one hand and a pen in the other.
  • Other players in the room: Business sponsors, project manager, business analyst, system architect, developer, test coordinator/test analyst, etc.
  • Everyone in the room starts telling the PMO dude what tasks they need to do and he writes each one down on it’s own stciky note and you also have to tell him how much time you think it will take you to do that atsk and he adds that to the sticky and then puts it on the wall. You don’t worry about order at this point, just getting all the tasks up there.
  • For example, if you are having 3 different requirements sessions, you would have a sticky for each one with the duration for each. You would also want a sticky up there for “schedule requirements sessions” so that you get the time included in the plan to book the meetings.
  • This is usually the end of day 1 – you’ve spent the entire day just listing those tasks and the time it will take to do them.
  •  After everyone gets their tasks up there, then you put them in the order they need to be done in.
  • You then draw lines with arrows to show what the predecessor and successor are for each task. For example, I would have to schedule the requirements session before I could have them so the successor of “schedule requirements sessions” would be the first requirements meeting and the predeccesor of the first requirements meeting would be the schedule requirements meeting task.
  • After you do all that, the PMO dude with the laptop lines everything up in Project.
  • They they tell you the schedule needs to be crashed because the way it looks, it’s going to take, for example, 3 months longer than they anticipated for the project to be completed.
  • That means you go through each sticky note one by one and the person responsible for each task is asked “do you really need that much time?” And you’re ALWAYS asked to shorten your times.

It can be a very frustrating exercise because you’re saying to yourself “why did you bother to ask me yesterday how much time it would take me to do it if you’re just going to tell me today that I don’t get that much time to do it?”. I’ve had those thoughts myself. However, I can say that I think it’s true that we do sub-consciously (and sometimes consciously) give ourselves a “buffer” in the times we give. I can say I rarely miss a due date for a task even though I had to shorten my time, so I do manage to get it done in that timeframe.

While I am usually exhausted after that two days, it does get the core project team together, gets people to take ownership of their tasks, and helps the team see everything involved in having a successful project. It also helps everyone understand how their tasks affect the tasks and timelines of other people on the project.

So while it’s not a party I would pick, it is one that I always attend.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.