Why does this happen? Well, when many people are involved in a specific ticket, there will be bunch of assigning, back and forth communication, until the ticket is approved, and resolved in the end. I am referring here to tickets that are related to new features or complex bugs. Dealing with simple bugs is easy and this would probably never happen.

How to deal with ticket readability

So, how to deal with tickets and avoid “noise?” You don’t want developers to miss out on features or bugs in the ticket and you also want testers to see what they need to review so it can be properly checked and approved.

I prepared a list of things we do to improve ticket readability and reduce the risk of missing valuable information.

Separate discussion from tickets as much as possible

We are lazy in nature, so from time to time, we tend to discuss things in tickets more than needed. Try to avoid this. Leave out all unnecessary information from the ticket and leave only clean concise data which is required for people working on the ticket. For additional details link to an external discussion, which is posted separately.

For example, say you are not sure how you want to implement a feature. The feature was discussed and final requirements are settled.

Now think about if you have all this information in ticket. This is a lot of unneeded data. The person to which ticket is assigned only needs to know about the final decision, and perhaps something else, but this can be all written down cleanly with a link to the discussion in which final decision was made.

Always attach links to the final copy and design updates to the ticket

When a developer is working on a feature, the ticket also includes a link to Beanstalk changeset and the latest design pages. Now these pages can change many times through the ticket. Attaching all the changeset changes and design pages at bottom of the ticket is a huge help.

Clean tickets reduce the probability of error

The bottom line is that you should try to keep your tickets clean and easily readable, at the same time try not to have long tickets which have thousands of lines of text. This means you should have separate tickets in smaller pieces.

Let me know what you think and how you are working in your task management system with tickets.

Communication is the key

In order to make products like Beanstalk, Newsberry and Postmark, you need to have great communication in the team. Without communication, projects would quickly lose their pace. We made a bunch of small improvements to keep everybody on the team happy:

Quiet time

When we are working, our goal is to not disturb each other,  so we don’t break the persons “mojo”. Every piece of communication that can wait is not discussed directly through IM. We use Basecamp, emails or tasks for this, depending on nature of the topic which needs to be discussed.

IM Status

IM status can be a really handy piece of information. It can help you figure out whether person is working, whether a person is super busy, when a team member will get back or whether someone is just hanging around after the work day. Although IM status-es are easy to use and pretty obvious, we started using them more intensively just recently.

Discussing features

When we are discussing features, we use Basecamp and include everyone in the team on topics, even if they are not assigned on the project. You never know if someone has a great idea.

Release notes

When we started using scrum, we started using release notes too. Release notes are quite handy. They are not just valuable for Chris (team lead), but it’s also a small retrospective of the work a team member has done over the last iteration. They give an insight for all members of the team about how the project is doing from a high level.

Posting plans

Another great method is posting plans for the work in previous 24 hours, progress at the moment and plans for next 24 hours. It’s one more benefit of using scrum in our virtual team. We tend to post plans in our morning meetings in Campfire.

Managing tasks efficiently

Managing tasks in a task system is never easy. After time tasks pile up and it gets harder and harder to maintain them.  We added a couple of rules to our process to avoid this.

Use simple states

We had a long discussion on which states we would use in the task management system. The more we talked about it, the more states we came up with. Hristo sugested that we use simple states, like

• not started – nobody is working on the task at the moment
• in progress  - someone is currently working on the task
• complete – task is complete and deployed to production site

and it proved to be the best choice for us. By using three simple states, we could easily define the state and have a clear view on the status. We added three more states (which I will mention later), but basically these three states are the ones used most of the time.

Assigning tasks and Milestones

When no one is working on a task, the task is not assigned. That is usually happening in the Backlog. We assign tasks to a person in case we know that person will work on it. Assigning a case is also a way of notifying the person by email about the task. Tasks are usually assigned when we are creating new Milestones. Milestones contain all the tasks you will work on, and usually last between one and three weeks. Two weeks is kind of optimal. If milestones stretch for too long, they get harder to maintain and deploy.

By the end of the milestone, all tasks in the Milestone need to be finished. Now, this is not always possible. Sometimes tasks in a milestone simply get out of hand and can’t be finished in time. In this case we move them to another Milestone, estimated with other tasks in hand.

Backlog and On The Radar

The Backlog is where we hold all of the tasks we plan to work on in the future. When there is a huge list of tasks, the backlog tends to turn into a place where tasks will “die” after a period of time, and will never be implemented. That’s why we try to look over the backlog after some time and clear it up. In addition to the Backlog, we use a milestone called On The Radar, in which we store backlog tasks which we will work on in the near future (next month or so). On The Radar can be handy when you need to figure out the next Milestone for the project.

Small things that make life easier

There is a variety of very small things that can make your everyday workflow easier. Here are some that help us out:

Additional Task states – approved, hold, invalid

I mentioned that we are using a few additional states next to the three basic states:

• approved – task is finished and reviewed on staging, but not deployed yet to production
• hold – task is on hold due to a variety of reasons
• invalid – the task was canceled out for some reason

I find the approved state above the most important. This state happens after we have completely finished the task, but did not deploy the updates to the production website. The task is marked approved and assigned to a developer. When updates are deployed to production, the task is assigned to QA, who checks the production site and marks the task complete (or not).

Allowing the team to be creative

Working on something different and new from time to time can boost your creativity. That’s why we introduced Open Source Fridays and Paired Milestones:

Open Source Friday

Open source Fridays allow team members to work on something different every other week, and to release the product of their work to the open source community. You can read more about OS Fridays in this post.

Paired Milestones

We’ve also started to explore less rigid work flows. An example is Paired Milestones. With this concept, we define some general high-level goals for a project and assign two people to accomplish it in two weeks. This could be a designer / developer pair, two designers, or two developers depending on the goals. Instead of having a project lead and specific tasks, the pair is completely responsible for organization, detailed ideas, and the outcome without outside influence.

What’s next?

We have no idea. When we take a look back, our workflow was completely different and we just can’t image how we could live without some of the improvements we have made. We are constantly improving and would probably say the same when we take a look back one year from now.

Preparing data

When you are testing existing or new features of your application, it’s very important to have adequate testing data. The more data you have, the more bugs can be spotted early in the testing/development stage.

Having good test data is very important for both manual and automated testing. Before writting the tests, it’s wise to think through and see which data you will need to run the tests.

Some of the questions you need to ask yourself before starting automated testing are:

• What functionality do you want to test?
• Will you be able to test the functionality (limits of automated testing tools, etc)?
• What data do you need for the testing?
• How do you organize the test cases to be reusable and easy to use?

Before you start writting the test cases, think of all the data you will need and the stages of the testing which will require it. This can save a lot of time and make your automated tests consistent. You will need to have data which is needed in all stages of testing (like login credentials), and data which would be used during testing. Managing data will probably include 4 steps:

• Prepare data needed in all stages of testing
• Prepare test data which would be used during testing
• Delete all data used during testing
• Delete all data needed in all stages of testing

By following the steps mentioned above, you will have the data you need during the tests, and you will leave the application data intact – by deleting all data you used during testing, you will get the system back in the state in which it was before testing. You should always make sure to set the application back to the original state, this way your automated tests can be run unlimited number of times and would not leave the application in an undesired state.

Reusability

When writing test cases, though you don’t need to be an expert programmer, try not to repeat the code too often. You would probably want to run those test cases daily, and updating a bunch of repeating code in your test cases can be hard and time consuming.

Always try to separate the parts which you will reuse often in your test cases.  For example, a developer changed a part of the code, which you test often. If you did not repeat your code, you would probably need to update your test cases in only one place. Same goes for data. I usually store data like login credentials and automated testing settings in separate files, so I can easily update them later.

Use meaningfull names for the test cases

Using meaningfull names for the test classses and test cases can be handy too. It will allow you to find the code you need to update easier. I usually call the test classes by the name of the section I am testing. For example, in web applications, I use the name “Account” for test class which will contain all related test cases to “Account” section in web application. This way I can also find the test class easier when I want to include/exclude it from the test suite for the next run.

Always be prepared

The most important part of automated testing, as for any other type of testing is being prepared: being familiar with the system which needs to be tested. Thinking through all the actions needed to create automated tests and organizing data and test cases will help you create a test suite (test cases) of high quality.

The features we miss

We have been using scrum for a while and we could not adapt it to Basecamp. It’s missing a few features that are basics for agile:

• Backlog – a place where we could store tasks that we are not working on currently
• Task states – we could not change the state of the tasks (started, accepted, delivered, etc)
• Prioritizing tasks – todo lists in Basecamp are not well suited for grouping tasks. If we add tasks to todo lists, we cannot prioritize them well, since some tasks in one todo list should have a higher priority than other tasks in another todo list

Not to mention that we don’t have burn-down charts, velocity, etc. These things are not top priority though.

Seeking a different issue tracker

The problem we had while searching for a different solution was that many systems out there try to improve things based on Basecamp. Then Petyo suggested that we try out Pivotal Tracker.

I had a look at and it seems that it is the closest solution to the agile principles and scrum I’ve seen so far.

Pivotal Tracker is much more complex than Sifter which I reviewed a week earlier (Review coming soon – Sifter’s biggest advantage is the simplicity, great dashboard, task type states and filters, though some features are missing like proper backlog). On the other hand, Pivotal Tracker has a very interesting approach to task management, and all the functionality needed to track tasks properly.

The main screen of Pivotal Tracker contains columns which can be changed based on what you need and want to see. Tasks are separated in iceboxes, backlog and current task list.

The good

Iceboxes

Iceboxes are place where you create tasks. In the icebox you have all the tasks that you plan to work on someday, and they are not ordered.

Backlog

Backlog contains all the tasks you plan to work on, but you did not start to work on yet. Backlog is ordered, and tasks can shift from it to current milestone dynamically.

Current tasks

The current tasks list is the place where you can find tasks which you are working on in the current iteration.

Velocity

One more interesting feature of Pivotal Tracker is velocity. It is the average number of points accepted per iteration, based on recently completed iterations. It measures progress, and allows Tracker to predict when milestones will be completed based on past performance.

Everything is in task lists

Pivotal Tracker is task oriented. Everything you need to see in Pivotal Tracker is related to tasks (releases, comments, backlog, current tasks) and can be seen in task lists named current, backlog, icebox etc. Even release date looks like a task. It is created in the same way as the tasks only it’s marked with a different type.

Not all tasks can have points in Pivotal Tracker, only features do, which is logical, since the estimates are related to the features, and when they will be finished, so bugs, chores do not have points.

Burn-down chart

Another great feature in Pivotal Tracker is the burn down chart which is generated automatically based on the work completed. It can be reviewed in the same way you would review tasks.

Search, group tasks

Pivotal Tracker also contains a way to have proper todo lists, by adding tags. Every task can have a tag which gives you an easy way of searching and grouping tasks.

Report generating

It contains simple report generating, although as far as we’ve seen, it’s disadvantage is that you can’t export them.

The bad

Well, on the bad side, Pivotal Tracker is strictly a tracker, so there is no way to use it for messaging, project specifications etc.. What we love about  Basecamp is that you have separate sections like messaging and writeboards, which can be used for communication and project specifications. But when you take a closer look, that is not a purpose of Pivotal Tracker, it’s not meant to be used as an all-in-one solution.

One more thing to note is that Pivotal Tracker is complex at first glance at it and requires time to get used to it. It seems it’s developed in a way so you have to follow the rules, which is a good thing.

The feature we would miss most from Basecamp is the communication between more than one person on a task. Pivotal tracker has it but it works in a way that only the owner, requester and all members who have posted comments are emailed when a new comment is posted. There is no way to choose users to notify. Also reply from email would be nice. This is the feature we seek most, since this could make it hard for us to communicate with the client directly about a task.

I must say that Pivotal Tracker is interesting, and a nice approach to management. We are still reviewing it, and who knows, maybe this will be our next task management system.

Review is still in progress

We’re trying Pivotal Tracker on a small project for now to see if it fits. In the mean time, we’re also trying some others tools to get a feel of what is out there. It’s almost impossible to tell if a tool is right unless you try it on a real project. Stay tuned for more reviews in the coming weeks.

We are in search of the good solution which could improve our process, feel free to recommend any other task management systems.

Selenium IDE

There are many different ways to automate tasks and Selenium IDE is just one of them. Selenium IDE has been around now for some time. It’s a small add-on for firefox which allows you to run and record tests for your web application. The reason I use Selenium IDE is because you can use it without almost any interference in your process of manual testing. Selenium IDE is lightweight and very easy to use and it’s constantly improved.

When I do manual testing, I cover the areas that I wante to test, and as I go, I turn on Selenium IDE and record tasks. I try to record scenarios that I will use later in other tests. These small Selenium IDE test cases are recorded so I will not waste time on common tasks, which would be repeated numerous times. Automating small tasks can speed up testing tremendously. This way you would spend time on reviewing parts of the application which are important, rather than spending time on common, everyday tasks.

Here is a simple scenario of my usual review of new functionality on our Newsberry project: Recently we released monthly plans, which required a lot of sign up testing. During testing of the sign up process, I recorded some scripts in Selenium IDE (simple html scripts), for signing up users, adding senders and activating them. This is the usual process you would use when you are creating a new account. Now, these scripts were used a lot during the review of monthly plans, but they were used a lot later during other reviews too. By recording small tasks, you can simply re-run them later, and not worry about doing the same process manually over and over again.

The beauty of the process is that it takes only couple of minutes to do this. These are not complicated test cases, test suites, no, these are very simple scripts, which everyone can run. You can simply send them over to developers, designers, and they can use it the same way you did, as long as they have firefox installed on their computers.

Dexpot

Dexpot is a great virtual desktop tool, which allows you to switch between desktops easily. I usually have a virtual machine located in one of the desktops, so I can easily switch between the operating system in the virtual machine and the one in which I run the virtual machine. With Dexpot you can easily configure every desktop separately, move applications from one desktop to another and many more.

Virtual PC

Virtual Pc is a free virtualization suite from Microsoft. It allows you to run different versions of Windows operating systems. In Virtual PC, you can use a free trial image of operating systems which you can download on Microsoft’s website. I use Virtual PC often for testing in IE6, FF2 and Safari browsers. 

Jing

Jing is a free screen capturing application from the makers of SnagIt. Jing allows basic operations like adding text, arrows, marking area, highlighting, and also allows making videos too. By the number of operations and quality it’s far from SnagIt, which is an awesome screen capturing application, but it is more than enough for basic screen capturing operations.

Taskbar Shuffle

Taskbar Shuffle is a very small, but usefull free utility which let’s you drag and drop your Windows taskbar buttons to rearrange them.  It can be very usefull when you have a ton of opened applications in your taskbar and you need to order them in some way.

Chris recommended scrum to the team. After a couple of months of experimenting and polishing the process, we are using it successfully in our virtual team.  I will show you how we are using scrum.

Virtual teams and scrum – no way

Before we start, you are probably thinking: scrum in virtual teams – no way, that’s impossible or at least there is no way to be as productive when you have team members all around the world. It’s harder to communicate with everybody when they are far a way, by IM or phone, different time zones, etc. It’s so much easier when the team member is sitting right next to you in the office.

You are probably right, but there are ways to get similar comfort in virtual teams, if you try hard enough.

Communication

The key for delivering a quality product is good communication between team members. You have to have good developers, designers, project managers, qa, but if the communication is bad, you will end up with bad product or at least you will miss your deadlines. Scrums forces the team members to communicate on the projects. To our team, scrum improved the communication and took it to a whole new level.

We communicate in three ways: Campfire, Basecamp and IM. For scrum we use Campfire.  Campfire is a place where we have 10AM meetings and hang around during work day.

Scrum meetings

Most important part of scrum are certainly scrum meetings.  We tend to have scrum meetings between 10 and 10:15AM, so everyone can continue working after that. If somebody forgets the meeting, he is reminded by the scrum master.  Our scrum meetings are bit different compared to the original scrum meetings idea. By scrum, in scrum meetings, team members should answer three questions:

• What have you done since yesterday?
• What are you planning to do by today?
• Do you have any problems preventing you from accomplishing your goal?

First we used Campfire for answering all three questions. But after using scrum for couple of months,  we realized that answering all three questions is unnecessary.  We use Backpack for tracking our work. By logging into backpack, everybody can see what was done yesterday and what everybody is working on currently.

Two questions need to be answered in our scrum meetings:

• What are you planning to do today?
• Do you have any problems preventing you from accomplishing your goal ?

and we post them in this form for easy overview:

[Plan] 1) publish presentation and continue with fixing N2 bugs 2) need to discuss N2 bugs with Andrey

This way messages are short and concise, and provide enough information for our team members.

Planning

For planning sprints, product backlog, sprint backlog, etc. we are using Basecamp. For product backlog we use writeboard in Basecamp, for sprint backlog we use Basecamp to-do lists. Clients can see what’s happening all the time with their project. You can read how we are using Basecamp here. We don’t have burndown charts for now, since we can live without them, but we plan using something like it in the future.

Sprint retrospective

To improve our process we have sprint retrospectives, but not after every sprint and not as four hour meetings.

Since we are using Campfire every day, besides scrum meetings, ideas of improvement come up. After discussing them, they are posted to Basecamp, where we discuss them further. This way new ideas are discussed on the way and tried out, to see whether they can improve our process.

We had the last retrospective a couple of months ago. One hour was enough to discuss process improvements. We use Campfire for sprint retrospectives too.

Summary

We are using scrum in our virtual team and we love it. Only real difference as we see it, is that our meetings are conducted in Campfire, not in the office. But that is not a problem if you are working with people who want to make things happen. In some situations, we see virtual meetings in Campfire as an advantage: it’s a place where you can always find someone to help you (now or later), which is not always the case in the office (what if the person is on second floor…).

Virtual teams are not perfect, but compared to a traditional office it has advantages and disadvantages. We are not complete strangers though, thanks to Chris, we met on the Wildbit retreat recently, which was an amazing experience. We do plan on using video conferencing in the near future.

Scrum improved are process significantly. Our team is more productive, aware of what others are doing and what obstacles might be in the way of finishing products on time.

Milestones

Each milestone contains the to-do lists and messages related to it. We use milestones as sprints. Milestones keep us focused on finishing small sets of tasks on a short and strict schedule.

To-do Lists

The key feature for tracking tasks is the to-do list (in other tracking systems usually called a ticket). Each to-do lists contains a list of tasks. To-do list contains a group of similar tasks, so for example, if we are working on “Login” functionality, the to-do list would look something like this:

• Login page
  • [Dev] implement login screen
  • [Design] Implement validation of fields
  • [Review] Implement forgot password functionality

In the example above “Login” would be the name of the to-do list, and below it, you would see the tasks related to it. Tasks are simply prioritized by order, which can be changed very easy in Basecamp by drag and drop.

Task tagging

Chris, our team lead suggested one more very useful feature, which we use when creating tasks – tagging tasks. As you can see in the sample above, every task has a tag: dev, design, review. Based on the tag type, everybody knows what kind of task types remain in the to-do list, and the team members can claim it, when they are available for work. Tasks with top priorities (tasks at top of the to-do list) are claimable.

This allows the team to work together, instead of one person assigning each task. Developers know which tasks are for them, designers have their tasks, and the client or QA can look at tasks with the “review” tag. This way each to-do can live through the life cycle of development.

Tasks with comments and attachments

The cool feature that made us realize that we can use Basecamp for bug and feature tracking, is that you can have comments in every to-do. You simply create a small to-do task, and we add comments and screen shots in it.

Allowing to clients to use basecamp

One more cool feature about Basecamp is that clients love it too, since it’s easy to use. We usually create a separate to-do list for them, where they can report the bugs or new features which they would like to see in the future. This way they are involved in the development process as well.

Prioritizing

The last step, after creating bunch of to-do lists is prioritizing to-do lists and tasks within them. So in the end, you have:

• prioritized to-do lists
• prioritized task lists within to-do lists

Anything else we need for tracking tasks?

Basically, that’s it! You don’t need anything else to start managing your project. By using simple rules for bug tracking and Basecamp you can easily manage your projects. Later, you will discover other features (most important: messages, overview and writeboard ) which will make managing your project even more efficient.

Summary

After using several different systems I can say that Basecamp is a very good system for project management. Not only that you can use it for bug tracking, but for messaging too. There is room for improvement, but I am sure it will get even better by time.

I put together a small set of tips for tracking bugs, ideas, and changes when working with software projects. We’re always trying to find the right balance between organization and simplicity. If you have your own tips, please let me know and post a comment.

Create small tasks

Bug tracking can be hard when there are a large number of tasks. What makes the tracking of tasks even harder are the large tasks. Sometimes people tend to put as much as possible into one task, or the task grows when assigning between members of the team (developers, designers, testers, etc.) with no intention, which is a bad practice. 

When creating tasks, they should be small, and should not include multiple tasks in them.  Split larger tasks into smaller ones. Create small tasks which can be easily reviewed by all members of the team.

Group tasks

Always group similar tasks into categories (groups). This way tasks can be tracked easier, and it will be easier to find them for all members of the team. Also try separating tasks by type (bugs, features, etc).

Write down steps to reproduce

For bugs, write down steps to reproduce for developers – try to avoid large number of steps for reproducing. Smaller number of steps to reproduce – easier way for finding the bug for a developer.

Task flow

Task should always get back to the person who created it or needs to review it. If it’s a bug, it should be always assigned back to tester. Only tester can close this bug, since he is the only one who saw the bug first and can be sure it’s fixed.  Task should never be closed by a person other than the one who created and assigned it.

Less means more

In your bug tracking system, try to hide the tasks which are currently not important – by filtering data or any other method which you find suitable. By seeing only tasks important for your iteration (sprint, deadline, milestone.. etc), the team gets a much better overview.