Scrum is a framework where the main purpose is to build better software, using common sense.
On this page we give an overview of some of the main concepts in Scrum.
We have a product (system) that can be a product that is beeing built from scratch or it can be a product which shall be maintained. In both cases the product should have a owner, which we will call a product owner. As responsible for a product, the product owner should have a vision about this product.
This product we will work on have some items that should be solved. We can call them items, activities or user stories. In short, they describe what shall be done with our product. We gather them all in an inventory, and call this inventory a product backlog. Anybody who has an interest in this product, can add items to the product backlog. To increase our understanding of the importance of this product, we ask the product owner to prioritize this list of items, and we tell the product owner that he/she can change the priorities in the product backlog, whenever it is necessary. We now have a list of all that we know needs to be done, and we do have the items in a prioritized order. To get a better estimate of the most important items, we want the top 20% of the items on the prioritized list, to be estimated, in no more than 10 working days (if more, break them into more items).
So, to get the top prioritized items solved we need a team. Our team must have the full knowledge, to be able to solve the items of top priority. Also our team has 7 plus minus 2 members, since research have shown that this gives the best team spirit. We also tell the team that you have no roles, you are crossfunctional and are in this together. Now that we want the team to concentrate on solving items from the product backlog, we need a Scrum Master. The Scrum Masters responsibilities is to facilitate and coach the team, and to make sure the Scrum process works.
We ask the team what they think they can achive in 30 calender days (22 working days). The team gets together with the product owner and the Scrum master to figure this out. First the team add how many hours they will be there the next month (excluding holiday, other work than from the product backlog, dentist, etc.). As other things happen at work, we ask them to calculate 6 hours as a full working day. The team adds up the number of ressource hours avaiable during the next 30 days. Then the team starts breaking down the product backlog, taking the top item, breaking it down into tasks with a maximum of 16 hours (we want to increase estimation). The team then take the next item on the productbacklog and brake it down to tasks. They keep doing that until they have reached the number of ressource hours, that where previously calculated (if a junior team, add some slack time).
We now have a team that have estimated how much work they can do during the next 30 days. So we ask them to the work for 30 days and call this a sprint. In order for them to succeed we must do what we can to optimize there working condition. First of all we have to leave them alone, we let them selforganize and decide for themself how to solve it. So only the Scrum Master have access to the team. Nobody else can ask them to do work, since we do want the team to stay comitted to there estimation during the sprint. Realizing that co-location is very good, we do what we can to co-locate the team.
To see how work progress the team and the Scrum master get together every day, same place, same time. Anybody can come to the meeting but only the team and the Scrum master can speak. Each team member share his/her work to the other by answering 3 questions : 1 What have you done since our last meeting? 2 What will you do until our next meeting? 3 Do you have any problems? Since we are also interested to see how many hours of work are left, we update a burn down chart with the total number of hours left for all tasks (we do not care what the team have used time on, we want to know how much work is left).
When the sprint is over, we ask the team to present there work. They do this by demonstrating what they have achived during the sprint. Anybody can come, but if the Product Owner is there it is beneficial.
Before the next sprint, the Scrum master and the team get together to talk about what went well and what did not go so good during the sprint. We then try to improve the teams productivity by making the necessary process improvements.
