Everybody’s talking about scrum. So what is it and why should we use it – if at all. Honestly, it’s a discussion I don’t want to get into, as with any other project process framework, it has it’s pros and cons. For this project I’m just gonna conclude it’s what’s used .

If you’re dying to know more about scrum check out the following links:

• Hamid Shojaee video about scurm on Youtube
• All knowing Wikipedia

Scrum in practical use

Scrum is a framework providing some work practices and artifacts to support the process and is implemented differently in different companies and teams. I’m gonna skip the theoretical discussion on where it’s used “right” and wrong” and just present how the process is being carried out in the context of this project.

It will look something like his.

To run through the steps quickly:

1. Some workshops to determine what it is we’re making.
2. If possible a small pilot project.
3. Specifications written as user stories
4. Test and fail fast – better and cheaper to fail now than later
5. Sprints and sprint meetings – as may as you need
6. Feature Freeze – no more new features
7. Code Freeze – no more coding…in theory
8. Performance test – may lead to more coding.
9. Grand opening of the project
10. Hypercare – users will break it!
11. Let’s see how e can improve in the next phase

In this project I’m gonna focus on the sprints and how to facilitate the work process when the team is geographically distributed. Scrum is made for in-house teams sitting next to each other being able ti communicate whenever they need. This is ont possible to the same extend when distributed.

What this project is about is how we can facilitate the daily stand up meetings through IT-system(s) and how to incorporate artifacts like the scrum board and the burndown charts. It’s about knowledge sharing, about bing up to date on other team members and about keeping them in the loop.