Sunday 21 February 2010

Journey from Scrum Padawan to Scrum Master


I have been a Scrum Master now little bit over one year and now I want to share my thoughts.

I have heard from time to time, that a Scrum Master job takes only about 5 - 10% of your time and frankly I believe that can be even less. If you use only minimum effort to be a Scrum Master, you need only summon couple of meetings (Daily Scrum, Retrospective) and that's it. If a team is extremely good and self managed you don't even really need to facilitate those meetings.

But if you want to take your job seriously and your organization and team is not mature enough, here comes the real work, and now I mean this heavy impediment removal. There might be huge things, like collaboration between different stakeholders. There might be some big technical problems, which are not easy to fix and they are affecting everybody's daily life. Your team can be really dysfunctional caused by some personal level problems. And you should also be the guy who are searching all the time better working practises and introducing them.

Question is, how to improve? 2 days Certified Scrum Master training is not enough, not even close but it's a good start. First thing is that you must decide that you want to be a better Scrum Master, after that learning by doing, starting to read books about the issue and following blogs, tweets and pod-casts of people who are practising this field of profession.

and my journey continues...

Monday 1 February 2010

Acceptance Testing Complex System

I want to share some thoughts about writing Acceptance Tests for a complex system.

General idea of Acceptance Testing is to write Test Cases to User Story which creates value to the customer. My argument is, that it might be impossible, in some cases to create User Stories for one team for one sprint, which creates really something usable. Reason for this is middle ware, complex technology, low level programing language. etc.

So basic idea for this, is to create Upper level User Story and create Acceptance Test Cases for that and those test cases are purely black box. After that you can break user story to as many smaller pieces as it's necessary and those smaller pieces can be really something which is not providing anything really working, but compilation of them creates value. Those pieces are still acceptance tested, but you can use more like white box and gray box approaching to them. Test Cases for Upper level User Stories are assuring that everything is implemented and nothing is missing because of splitting.