Happy new year and project

8. January 2010

Happy new year

How many times did you leave your project for vacation with a bad feeling about what would be when you come back especially when the old year is about to end and a new year is about to begin? To be honest, too me this happened more than I would actually like to admit. However, this year something had changed. Neither I had a bad feeling when I went nor when I came back. What a surprise?

Not really. What did we change for that? Let’s look what main three reasons are there why I did not feel bad when I left the project to go on vacation.

The project mood

This time I am running an agile project and it is based on a team that feels happy and responsponsible. Some of us went earlier and came back later from vacation, though there were a few people left to do the job in the meantime. Everyone of us though knew they would take care of the things that have to be done. Granted, we decided to slow down the pace around Christmas but still there was enough work to do.

The work to be done in one or three weeks? or two?

Through the last weeks and months like in every project there are things that kind of pile up that everyone of us wanted to do. Even though they had value some other things were somehow more important. Also we noticed that we had collected  some bugs over time that we wanted to be taken care of. While we do have a sprint of two weeks and we never have changed it, it turned out that the latest sprint would start only one week before christmas. We now had the possibility to extend it over christmas but that would have lead to an end that would have been around new years eve where noone would have been there to come together for a sprint review. We could even further extend it until the 5th of January making it even three weeks. So, are we allowed to change the sprint from two weeks to one or three weeks? Keeping in mind that this is an exception to the rule and we wouldn’t like to blindly obey  rules, this time we decided not to shorten but to extend the sprint – but in a planned manner: We had fewer people on board with an extended period and again planned every thing like before. Looking back this was a good decision because Agile is about a sustainable pace and why not slow down a bit at the end of the year.

Doing the right things

However, if many leave the ship for some time there is the tendency that everything slows down a lot. A team consists of different archetypes of people. There are experts, workers, thinkers, drivers, genies etc. When most of the drivers are off, the team “drive” changes. Besides that we decided to name this sprint a “quality assurance sprint” which mostly consists of bug fixing and todos. The danger was that the team would “just” go along and would work on one thing after the other without really knowing where they would finally finish. Especially in this situation it was important that everything that should have been done was planned like in any other spring before thoroughly. People tend not to plan bug fixing which is extremely dangerous (especially when a team changes a lot). Therefore we did one trick:

We wrote down user stories that bundled bugs into topics like

  • fix bugs in the area of the frontend
  • fix bugs in the area of topic 1
  • fix bugs in the area of topic 2

Each of those user stories contained links to multiple bugs that had to be done. This way we achieved the following results

  • People were efficient in fixing the bugs because they were all in the some business or technical domain
  • People didn’t get distracted by the amount of two small work portions to be done
  • The bundles were like user stories because the business value is that a certain business domain was again fully functional
  • As the bundles became much more similar to user stories they turned out to be easier to be estimated

One tip at the end

In this kind of a QA sprint make sure that even the bug fixes that become like tasks for the “bug bundles” are actually all completely estimated. Even though it is harder to estimate bug fixes than new features it is still very important for the team to understand its status quo during the sprint.

As I came back all bugs were fixed (or questions were asked because of unclear circumstances as the product owner was on vacation too – hence, make sure that you talk about the user stories thorougly before starting the sprint) and the team was (almost) done. Everyone had a good feeling. We were again up to great quality and everyone was happy about a fresh start into a new year…

The above illumination was taken in a mall on the german island Usedom in the city Heringsdorf during a night shopping tour.

Trackback URI | Kommentare als RSS

Write a comment