Archive for 2009/05/06

Handling requirements during and after a project

The common image of agile software development is the crowded team room with lots of whiteboards and lots of post its (or story cards of some kind).

Now, I’m struggling to live without paper print outs and is currently pushing 9 months without making a single print out (I took a couple of months off before my new position at TUI Nordic and since I’ve never have had a printer at home, I didn’t print anything then) of which 4 months have been on my new job as a project manager. Yes, you read correctly. I’m a paper free project manager.

So, using a lot of papers which I dispose of all the time does not play well with me. And also, since some of my most important stakeholders are in different countries, I have to rely on digital formats for my backlogs.

But I’ve also seen another problem with paper product backlogs or sprint backlogs. What happens to them after the sprint or project is completed? How can you spot trends or track changes in requirements during a project?

I’ve learnt a lot from looking at old sprint backlogs and looked at trends, specific topics and problems. But how do you do that if you throw away the stuff when the sprint is over? Well, perhaps you document it as is but I don’t like the dual job.

So, I’ll stick to my digital backlogs and use them for analysis during the project.

But then we move into the next problem; how do you keep this documentation after the project is completed. When you work within a project, you need to compare the data within the project. But afterwards you need to see patterns between different projects. we’re currently looking into how we can document requirements between projects using ARIS. This will be an interesting challenge.

Categories: Agile