The first sprint is done! Yes we finally started doing Scrum at tilllate.com*. Well, it’s not exactly how Schwaber and Sutherland would expect it. But our way fits our team. And the acceptance in both the IT team and the rest of the organization is high. It improves motivation and therewith the performance of the team. And that’s what matters.
Sprint planning meeting
Here’s how we do it: Martina, our product manager for the website is the product owner. She collects all feature requests from the clients. In the case of tilllate this might be photographers, sales guys, visitors from the website. These features make up the user stories. She prioritizes these user stories lets the CEO sign them off. This creates the product backlog.
Sprint planning
Enters the IT team: During the sprint planning we go through every item on the product backlog. Martina explains each user story. The team does an estimate in story points. Once the estimation is done, every team member can choose which user story he would like to implement. This takes roughly 2 hours for a 3 week sprint.
This information is tracked on our scrum board which has a swim lane for every developer. Every user story is a post-it.
Scrum board
At the end of the sprint planning every developer knows what he has to do in the upcoming sprint.
Daily scrums?
No, we don’t do daily scrums. Yet. As my developers are not used to daily meetings I did not want to shock them (“Change management”). We started with bi-weekly meetings where we update the scrum board and the burn down chart.
Sprint review
At the end of the sprint we are doing a demo and a review of the sprint. In the demo every developer shows what he has accomplished during the sprint. This anticipates the feeling of “I did not get anything done” that so many of us have. The sprint review is a performance and problem analysis of the sprint. Did we meet our goals in term of story points? Why not? What can we do to meet them in the next sprint?
First experience
Today we had the sprint review for the sprint “1” and had the sprint planning for sprint “2”. Here’s our first experience:
- Hot: The IT team is much more motivated than before we used scrum: They can choose themselves, what they would like to work on. And they have a goal
- Hot: As the IT team is doing the estimates they are committed to meet them. They are more focused.
- Hot: The product owner and the customer is happy as they have a high transparency. They always know what the team is up to. This increases trust in the IT team
- Not: We committed to 58 story points. At the end we only accomplished 23. That’s an awful velocity 39%. Bad. We had to take a number of measures for sprint two. For example: Decrease velocity down to 70% and better estimations.
Burndown chart of the first sprint
*Thanks, Peter Stevens, Leo Büttiker and Maarten Manders for motivating me to try it.
Hi Silvan,
Congratulations for completing the first sprint 🙂
It tooks us around 4 sprints to get a good routine in “sprinting” and staying on the burn down chart line and not above it.
Now we are used to it and its great!
We started to use scrum as a development method in 2004. Since it’s a rather flat pm model that is easy to understand and actually embraces change, it fits the demands of a php company pretty well. While a lot of things changed since that day, we are still experiencing trouble – even things like “customer changes mind in the middle of the sprint” or “let’s do one week more to get everything finished” do still happen from time to time, and – surprise, surprise – it always results in even more trouble :-).
Learnings we’ve made: a burndown chart that has not been updated for a week is useless. a scrum master that does not know how many impediments he solved last week is not a scrum master. In complex environments a velocity higher than two can easily happen.
Good Luck!
Johann
(Who should write a blog article about the programming infrastructure at mayflower, based on scrum, xp and crystal clear)
Great acheivement! I love the ‘analog’ charts.
Actually, your 39% is not so bad a velocity. The interesting part is that you probably had 39% all the time, and you just managed to make it visible. Now you have a number for sprint two.
What you’re investing in is in those aspects of motivation and focus. It already increases productivity and will continue to do so.
Now I’d like to know how many of your managers would rather not see that number and would prefer to go back to the comfy misty illusion of gantt charts 🙂
I hope you’ll post a blog about the rest of the sprints too.
Pingback: Dev Blog AF83 » Blog Archive » Veille technologique (x2) : Annonces, Contenus, Conférences, Méthodes, Agilité, Développment, Langages, Editeurs, Outils, Bases de données, Protocoles, Bibliothèques, SEO, Ergonomie, etc.