Scrum principles:

1. As soon as there is a problem, identify it. This is important, because the faster a problem
is identified, the easier it will be to pick up. Problems can be logged on the
"Impediments" tab in the Sprint backlog (More of this later).
2. Analysts know how to analyse and the developers know how to develop. So just leave
them alone and let them do their work. In case you need something to ask, go to the
Scrum master (see Scrum roles). Important is that the analysts also need to need to have
basic to medium knowledge of programming language and the developers need to know
how to analyze or read an analysis. Actually, you don't speak anymore of analysts or
developers but of a team that works together.
3. Make iterations that are not too short or too long. A theoretical/practical good iteration is
30 days. Keep the length for every sprint (see later for an explication) the same. The
advantage is that everyone (the team and the customer) has the feeling at the end of a
sprint that they end a real product.
4. The team must be self-organising
5. Try to work on one theme each sprint
6. There must be one team room, not 4 rooms for all team members. Communication is
very important

Scrum activities:
1. Sprint planning: This is the first day of an iteration. It takes 4 hours maximum. The
customer sits together with the team, shows the product backlog (see later for an
explication) and explains it. Also he gives his priorities to the items on the product
backlog. Then the team discusses everything and makes an agreement on what they will
deliver within this iteration. Best is that each sprint is centered around one theme (e.g.
Database Application, Financial Services,...)
2. Sprint planning part 2: In the afternoon, the team sits together to discuss everything and
to expand the product backlog items in smaller tasks of maximum 16 hours for each task.
The manager (product owner) doesn't assign tasks to individuals, doesn't make decisions
for the team.
3. Sprint itself. During this period the team does the analysis, the programming, testing and
documentation. At the end the team will deliver a Potentially Production Ready Product.
4. Daily Scrum: This daily meeting is held in the beginning of the day. It takes only 15
minutes during which the team tells what they have done the previous day, are there
problems and what are they going to do during that day. Cannot be used to solve
problems. The chickens and pigs (The pigs are the team themselfs, the chickes are
people who are just interested in what's going on) are invited. This will help to avoid
unnecessary meetings. Only the pigs can talk. The advantage is that the team sees the
whole picture every day and it creates a pressure to do what you have said you will do. It
can't be replaced by emailed status reports.
5. Sprint Review: This is the last day of the iteration. The preparation time needed by the
team can be maximum 2 hours (the day before). In this meeting, the team will
demonstrate the new functionality to the customer (and all the people who are
interested). Typically it takes the form of a demo of new features or underlying
architecture.
6. Sprint retrospective: This meeting is held only by the team leaded by the scrum master
(see later for an explication). During this meeting they will make a review of what
happened during the last sprint. What was good, what could be done better,...?
7. Sprint Stabilization: This is a short sprint around 2 weeks to stabilize the product and
implement it in test or production.
 8. Sprint Refactoring: Almost the same as the Stabilization Sprint. Only that this sprint is
needed to refactor the code.

Scrum practices:

1. During the project identify the Impediments and remove them as soon as possible. These
Impediments are written down in the sprint backlog.
2. Identify the Product backlog
3. Define the Sprint backlog
4. Be sure that no one can disturb the team. The Scrum master must ensure this
5. Product is designed, coded and tested during a sprint.
6. No Changes are allowed to the product backlog during a sprint.
Scrum products:

1. Product backlog: Is created by the customer (product owner). This backlog defines
everything to cover his needs. Every item has a priority. This product backlog is
explained on the Sprint planning meeting. The team itself can also add tasks during a
sprint for the next sprints, when they have the need that this must be written down to be
sure that will be done (impediments). There are two kinds of product backlogs : We can
have a functional or a technical product backlog.
2. Sprint backlog: the scrum master defines this after the sprint-planning meeting. It
contains all the 16-hour tasks divided in sub categories. Also the hours a team member
can work during this sprint is written down. Further included is also the team burn down
and the individual burn down graphic is added. With burn down can be explained as a
graph wich tells us how fast or how slow we go on a all our tasks. A good thing is to use
a team member anonymous on which all task are defined. When a team member takes a
task for him he changes the anonymous user to his name. This way you don't have to
delegate the task before to the team members and everyone can decide every moment
what he wants to do (Of course, at regular times the sprint backlog needs to be reviewed
to ensure that all tasks are performed before the end of the sprint.). The sprintbacklog
can only updated by the team.
Scrum roles:

1. Scrum master: The facilitator of the project. He's one of the succes factors for the
project. He must work together and support the next 2 roles. Typically this role is filled
in by a Project manager or Team leader. He is also responsible for enacting Scrum
values and practices. His major job is to remove the impediments.
2. Product owner: he is the customer. Acts like one voice (even if it's not one voice).
Typically this is a product manager, someone from marketing or similar. The major
responsibility is that he knows what needs to be build and in what sequence this should
be done.
3. Scrum team: the team itself. Typically the size is about 5 - 10 people. Must be cross-
functional and those people must work together. Members must be available full-time for
each sprint. Some exceptions to this full-time availability are possible, e.g. System
Admin,...). Team members can only be added or leave the team between Sprints. The
team is self-organizing, so in principle no project leader (like in a standard project
development) is in role, but it could (although this job can be done by the scrum master).

Burn Down:

You must be aware that the scrum team has a good burn down.
• No work:

• Work but not fast enough

 • Work but too fast

What covers Scrum:

As you can see, every meeting type has it's own coverage. The only link that is missing is
between the Product Level and the Development Level. But this is solved by the needs of tasks.
Conclusion:

Comparing tradition approaches versus agile we could say:

Traditional:

Traditional methodologists are a bunch of process dependent stick-in-the-muds who’d rather

produce flawless documentation than a working system that meets business needs.

Agile:

Lightweight, er, “Agile” methodologists are a bunch of glorified hackers who are going to be in
for a heck of a surprise when they try to scale up their “toys” into enterprise-level software.

1. If you want to use agile, try to brew your own cocktail:

Inception: Develop in pairs (Analyst architect + user) and remember your backlog.
2. Elaboration: Develop in pairs (analyst/architect + lead developer) and continue to make
the use cases
3. Construction: Multiple XP teams developing different parts of the architecture. Scrum
Master for each team – with Project Manager over all and cross-team pairing for interface
and infrastructure issues
4. Transition: Integration of different parts of the architecture, but also pairing for fixing
bugs and integration
5. Start with XP: Use 1-month iterations
6. Add other Scrum practices: Scrum master a protection/insulation of the team
7. Add use cases from RUP: Architects pairs with marketing staff. Marketing sells use
cases to the world, while architects converts those use cases to the developers.

Scrum in a few words:

 1. Is an agile, lightweight process
2. Can manage and control software and product development
3. Uses iterative, incremental practices
4. Has a simple implementation
5. Increases productivity
6. Reduces time to benefits
7. Embraces adaptive, empirical systems development
8. Is not restricted to software development projects

Still remember:

1. There's no ideal development process

2. Always tailor your process and methodology based on following requirements:

a. Scale of project (small team, > 100 developers,...)

b. Type of project (real-time, medical,...)
c. Experience and type of resources
d. ...

Scrum and Visual Studio Team System 2005:

In Team System Microsoft has added the templates to use agile methodologies. It's Microsoft's
own definition. A part of it is likely Scrum, but you have to recreate your own templates. Or
you can go to
http://www.conchango.com/Web/Public/Content/NewsRoom/PressReleaseDetails.aspx?
PageID=270. It's still in development

My experience:

When people are leaving on holiday during a sprint, especially in the beginning or at the end, the
Scrum Community gives us a good solution :

When folks can't attend sprint planning, reviews, or retrospectives, I suggest they provide
proxies
that can fully represent their interests. This keeps the rhythm going and has the added benefit of
cross-training (pairing of sorts for the proxies).

We are going to try this principle during the sprint of December.

Another thing we discover is that at the end, sometimes people don't know in detail what 's done
by the other team members. We have proposed a few solutions to the scrum master about this.

1. We do intern sprint reviews in between (max 2).

2. Every monday morning we will create the tasks for that week.

A scrum team is minimum 5 people and maximum 9 people. Our experience is that 7 team
members is the maximum in one team. If you have more than 7 people, you must divide them in
more teams. For each team there will be a kind of Scrum master who discusses the overall
picture with the other team scrum masters and the scrum master.

The anonymous teammember only is not good enough. It could happens that some important
tasks are not picked up by someone. So we decide that the main blocks are not assigned to the
user anonymous, but to a teammember. This doesn't mean that he has to do this task, but he has
to follow up that the tasks defined in this main block are getting done at the end of the sprint.

And last but not least (at this moment). Several team members still think that the sprint backlog
is a kind of time registration tool. This is not the case. Every morning you have to fill in the
Sprint backlog with the time still needed for the tasks you picked up. This means that when for a
task of 20 hours you have worked 8 hours, you still can fill in 16 hours to go.

Links :

http://www.controlchaos.com
http://www.scrumalliance.org
Scum user stories : http://www.mountaingoatsoftware.com
Scrum Community : http://groups.yahoo.com/group/scrumdevelopment/
Short description by William Wake : http://xp123.com/xplor/xp0507/Scrum-dev.pdf
Howard van Rooijen : http://blogs.conchango.com/howardvanrooijen/archive/category/32.aspx
Conventional Software Testing on a Scrum Team : http://osnews.com/comment.php?
news_id=12067
Scrum in Project 2003 : http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/odc_pj2003_ta/html/OfficePJScrumToolSolStarter.asp
Scrum Solution Starter : http://www.microsoft.com/downloads/details.aspx?
FamilyId=81DAAB54-6701-4FBC-B3D0-7F261383F371&displaylang=en