As a project gets closer and closer to handover to QA, I find myself tracking a list of outstanding items that need to be completed before the software is completely ready for testing. I'm trying to think of a way to do this that's more rigorous and visible - so that everyone is aware of what needs to be done and so things don't fall off the table. One possibility I'm considering is simply logging problem reports (trouble tickets) on the items which are outstanding. Would it be better to add them as explicit tasks to the project plan or is there a better way still?

3 Answers 3


For me the answer is hidden in a question. You want to make these things visible? Well, make them visible. Visualize your punch list, possibly on a physical medium and in a place which is frequently attended by the project team, be it a room they share, a hall or the place next to a coffee machine.

Using physical medium - a whiteboard or flipchart serves two purposes:

  1. It gives a big picture to everyone. If the list is in bug tracker or something I likely filter out items which aren't assigned to me, thus I don't see what others have on their plates, thus it's unlikely that I consider helping them. With a physical board I want it or not I see the whole thing.

  2. It makes the message more accessible by everyone. Whenever people are walking by the board they will take a quick look at it and possibly learn that something has changed or there is a problem with one of items etc. It is sort of learning "in the meantime." That's why the more crowded the place is which you put your board in the better.

There are also a few pleasant side effects:

  • Physical board is extremely flexible. You can draw a picture if you like, or attach a sticky which means something, e.g. a blocker, or have cool avatars of people who are assigned to tasks, etc.

  • It serves as a continuous reminder what else there is to be done. You can forget to log in into the app which stores your list when under heavy workload but you will eventually take a look at this big thing on a wall.

  • If the board is in a room the team works in you get additional information - everyone sees that someone comes to the board and changes something, thus they get an update in a very non-intrusive way.

  • It is a place where you can meet during project meetings to discuss most important and urgent things to deal with.

  • It gives you the place where you can do some brainstorming without losing a context. You can just use the empty place on the board.

  • It is fun. Definitely more fun that yet another bug tracker.

  • Unfortunately, this isn't physically possible for many teams nowadays because of their virtual nature. I'd offer that something that's easily put 'in your face,' not too cluttered with details and that's easily added to/updated is what's really needed. For this I've seen the landing/home page of the most commonly used tool as a good means to do this. We use the home page of our team's Sharepoint site to display this type of info.
    – user3746
    Commented Apr 4, 2012 at 19:52
  • That's true. In this case it is a question of value: one solution might be physical information radiator/board in PM's place if the focus is on PM tracking down each and every issue, or software based solution, as flexible as possible which is easily accessible for everyone in the team, or a combination of both. Either way, if physical board is feasible I'd definitely go for that. Commented Apr 5, 2012 at 8:49

Try a bug tracking application or issue tracking application. Many people have given great suggestions on the site under the PM Software tag.

  • It's more of a process question than a request for a bug tracking app recommendation - we have a bug tracking app. Commented Apr 4, 2012 at 15:58
  • Thanks, that clarifies it. Who is responsible for completing the tasks? Are these outstanding items for yourself, for the development team only or for various people on the team? Do these items need to be tested/validated during testing? Commented Apr 4, 2012 at 16:50
  • Various team members have tasks; yes, this work would be subject to scrutiny by QA. Commented Apr 4, 2012 at 16:53
  • Then yes, included them as explicit tasks on the project and as items to be validated in QA. Commented Apr 4, 2012 at 18:25

Does everybody need to be aware of what must be done? I think this might cause you more troubles if you have nearly completed development.

Regarding issue tracking. If it's a bug/defect/issue, then it should be formally logged, analysed and then tasked up. E.g. I found a bug on the live system. I have logged it. Front end senior developer has picked it up and analysed it. Another web developer knows how to fix the bug, so he then tasks it up, gets it approved by relevant parties and then starts development.

If it's just a task/feature, then it needs to be analysed in exactly the same way.

It doesn't matter at this stage whether it's in a bug tracking application, document sharing application or excel. As long as it's consistent and clear - you'll be fine.

Relevant stakeholders must be aware of this feature/task/bug, NOT everybody.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.