SCRUM

18062008

Some time ago I was introduced to some of the scrum principles. Coming from a waterfalll based background, and being introduced partly to scrum it felt wrong.

Some time has passed since that and a I’ve read a couple of books on scrum, and been so lucky to take Jeff Sutherlands certification course on scrum. Seeing scrum in a new light, it feels right. Namely because coming from a waterfall based background, I’ve never seen a project using waterfall complete in time and/or get the customer satisfied with the feature set.

So to summarize what I see scrum are about

Giving control to the right people, and by doing that you get the benefit of them committing to their work, on a completely different level than otherwise.

Realizing that no project can be specified once and then written, it’s fluid.

I’d recommend for the scrum master to create the issues and then assign them to whoever it were agreed upon in the scrum daily meeting. And do remember that you still need the white board and yellow stickers, to keep it fast and simple.

So heres something like scrum in 5 minnutes:

Roles

In scrum there are 3 roles, team member, scrum master and product owner.

Scrum masters role are to remove impediments and oversee the daily meetings, and keep track of team progress.

Team members role are todo the work, estimate, maintain sprint backlog and tell about impedients.

Product owner maintains the product backlog, sorts it probably by a business/complexity ratio once estimated by team. This should be a represent from the customer if you have one, or maybe a marketing represent.

Tools

Burndown chart, every issue has remaining work hours and that make it possible to create a burndown chart. Scrum masters use these to document progress.

The whiteboard for tasks/issues are divided into three categories, sprint backlog, inprogress, done
. Team members/scrum master uses these to keep track of progress within a sprint

Product backlog, which are maintained by by the product owner. This backlog are sorted so the next important issue are first.

Sprint backlog, maintained by the team. Inhere they take what they believe they can manage to complete for the sprint.

Flow

Pre sprint planning/work

Here it’s important to maintain the product backlog, this goes for both the product owner and team members, since the product owner cannot prioritize without without story points. As a best practice it’s good to give external dependencies a special mark, and if they aren’t completed halfway through the sprint it’s probably not gonna get done.

Sprint planning

Here the team creates the sprint backlog.

Sprint

Here all the work are done, each day the team meets at their daily standup scrum meeting (taking no more than 15 minnutes) and says shortly what they have done, are about todo and if they have any impediments.

At the end of every spring there are sprint demo and the idea are to be able to go live with what you have accomplished so far.

General rules

The team, Scrum master and product owner have the ability to abort a sprint if everything are going very bad.

Actions

Information

2 responses

[…] We try to adhere under the ideas of people like Robert Martin (whom have summed up a lot of ideas of other people), go grab clean code you wont regret it. In short write code in a minimalistic readable way, remember to test it, care about your code and smile. Clean code really has summed it all up. Although there’s a lot of books on the topic’s of coding, testing etc. It’s my favorite. Oh and do not forget something like scrum. […]