13 Comments First -Scrum- impressions - 01/29/09
About a month ago, I finally got the opportunity to do a Scrum-project.
I’ve got to say, I don’t want to go back to waterfall, never. It’s been freeing and fun working this way. I feel the days are flying by as I speak. It feels like yesterday when I think back to last saturday, while it’s already thursday evening. And that’s a good thing. When I’m bored at work, I get completely demotivated and minutes seem hours.
Actually I learned a lot of new things. I already knew a bunch of things about Scrum and Agile in general, but only things I had read, and reading is way not the same thing as doing . Let me tell you the things I’ve done, what I liked and what I didn’t like.
Our product backlog started out as a few notes in a notebook and some pictures of sketches we had drawn on the whiteboard during the initial meetings. It turned out to be a Word document, containing all the requirements for the application (in the form of user stories). Everyone can consult them, the whole team can change them. Every user story has a little summary of what the requirement is, an estimate in points and that’s about it. We try to write the user stories from the user’s persepctive. They contain no technical information, we write them down just like the user explains his need. An example could be: Link contracts to each other. How we’re exactly going to implement this, is of no importance at the user story point.
After each sprint planning meeting, we create a sprint backlog. This is a document containing a more detailed view on what we should implement for each user story during this sprint.
Actually, it contains what we wrote down on the product backlog. This description is extended into more detail.
Sprint review meeting and demo
After each sprint, we plan a meeting in which we review the past sprint. This only includes the team. We also demo the features implemented or fixed during the sprint to the user. A new version is available on a user-acceptance environment. The users can test the application, make remarks, add new features to the product backlog, or report bugs. When we finish the sprint review meeting, we start with the sprint planning meeting for the next sprint.
For this project, we chose 2 weeks for the duration of a sprint. I think this a healthy choice and until now, we’ve been able to meet our deadlines without any hazzle.
Things we’re not doing
Burn down chart
This is a chart that is hanged up in the middle of the workplace, updated every day, to reflect the remaining work for the current sprint backlog.
In stead of working with 3 panels (Not assigned, ongoing, done), we do this directly in TFS. We created a user “Unassigned”, to whom all workitems (or tasks) are assigned when starting a new sprint. Then, whenever we start with a new task, in stead of putting the post-it note in the ongoing-panel, we assign a workitem to ourselves. When we finish, we close the workitem.
Things we should improve
In my opinion, we should pay more attention to this document. It’s not detailed enough and the tasks are not broken down enough. On Wikipedia I read that every task may not take more than 16 hours, and this is not at all the case right now. It should also contain more detailed and technical information about how and why to implement the tasks. Each task could also have an estimate assigned, which is clearer for the team during the sprint.
Now, we don’t actually do the standups as we should. We do them, but not necesseraly in the morning. We do it at any time of the day, and anyone can initiate it. We all gather up and do our talk at someone’s desk. We usually don’t pass the 15-minute limit, so that’s a good thing. But we’re already working on the improvement of this one
What I find hard
During functional meetings with the users, we talk about wanted features. We get into more detail about how we could solve the problem. What I find very hard, is not getting into technical details. We start talking about business logic and database structures, and we completely lose the focus of the user, since this is not a technical person. But I really think we need to do something about this, because this is not at all pleasant for the users. It makes meetings much longer than they should last and sometimes quite boring for the functional persons. I think we need the Scrum-master to try to block the technical talk more. It’s normal for developers to think of implementations, but that’s just not the concern of the users.
After all, I’ve enjoyed this 4 weeks a lot, and I’ve learned quite some new stuff during this time.
In addition to practicing Scrum, I think we’re also being quite agile (and I like it). I’m also starting to read more about scrum, and about agility in general. I’ll be reading the following books:
- The art of agile development, James Shore (ordered)
- User stories applied, Mike Cohn (reading)
I’ll bother you with the reviews when I’m done