One of the bugs I was verifying included a very helpful dev comment in the bug report. The dev wrote:
“I came across this one and thought I'd just knock it out. No big deal, easy to do, easier to test.”
If you saw this dev comment in a bug report, what would you do? I’ll tell you what I did… sat down at my desk, rubbed my hands together like a fly, then attacked that fix like the world was watching. After a few tests I found the oversight I was expecting.
“thought I’d just knock it out”
“no big deal”
“easy to do”
….maybe that’s just a developer’s way of saying “Be careful, I did no testing whatsoever on this”.
I think all the project teams in my department are finally using Task Boards. We’re split between an Atlanta office and New York office so we still keep our electronic version as the master. We use Microsoft Team Foundation Server (TFS) to track all work items (Features, Tasks, Bugs, and Tests). We use Telerik Work Item Manager 2010 to print our work items into cute little cards with descriptions to move around on the task boards.
Each team came up with their own task board location and layout (e.g., column labels). Some teams use bug or test case task board items while others stick with just Features/User Stories. The variety of approaches is necessary because some teams work on smaller-scale low-risk projects while other teams work on highly complex SOX compliant applications that require more rigor.
Here are a couple good ones.
...making your velocity public is classy.
This one is way too confusing. I think that white board would be much better used as a space to diagram ideas. I just see chunks of stuff. I have no idea what is being worked on.
This one is just ugly. This was a technical debt iteration but after the initial card print-outs, everybody got lazy and just drew work item numbers with a marker. The testers wasted about 30 minutes per day trying to determine what each number represented so they could move them to the correct column as testing completed.
- We often get TFS and its respective task board out of sync. This means the task board can mislead.
- Adding/Moving work items on the task board is extra administrative work. Sometimes we get lazy and just write work item #’s on the white board. We quickly forget what these represent. That is one advantage to cork boards (you can’t write on cork boards).
- Management types don’t have to ask as many questions, they can look at the task boards instead.
- When stakeholders ask for extra stuff, we can point to the task board and say “no problem, just tell us what we should remove from the iteration”.- the team gets an extra simple view of how the work is proceding.
- Instead of staring at each other’s ugly mugs, we can look at the task board during scrum meetings.
- It is easier to get excited about team accomplishments when your work is public.