General scrum master newbie questions

1: You need to look at the business needs of the overall system, but you should not aim for a requirements specification unless the customer wants Fixed Price + Fixed Scope. If the customer wants Fixed Price + Fixed Scope, Scrum may not be a good match for the project.

2: You should aim for something that actually works after the very first sprint. It might be something very simple and basic, for instance a log-in page with only one username/password combination working. However, it should work. Every sprint (also the first sprint) should result in some increment of working software.

3: Everybody on a Development Team in Scrum are involved in software development, because software development is not just writing code, but analysis, design, testing etc. are all part of the game. There is usually plenty for everybody on a Development Team to do. Team members can for instance begin looking at the top priority items on the Product Backlog to ensure that details are in place before the items are selected for a sprint.

4: Scrum Master is a management role, and the Scrum Master manages the process itself. The SM's most important responsibility is to facilitate and ensure that the Scrum process is followed. SMs benefit from having a solid network within the organization, because this will help getting impediments removed. Unless the entire team is staffed with experienced employees and they all have a solid understanding of Scrum, I would not recommend switching Scrum Master that often.

5: The design of a feature should be decided upon during Product Backlog Grooming (an activity that happens during the sprint). The team should not accept product backlog items into a sprint backlog unless that item is well understood. During the sprint, the team may break down the sprint backlog item further, and it may happen that the team realizes that the sprint backlog item cannot be done in the sprint. In this case, the team should talk with the Product Owner to find out if the product backlog item can be split into smaller items, that each provide value to the customer, or if the item should be left out of the Sprint Review and added to a later sprint.

Kindest regards, Mikkel

[Sorry for the duplication. Using my phone for reply by email doesn't appear to work terribly well.]

1. Scrum is definitely meant for building the new and unknown. Please take a look at both the Scrum Guide and the book Software in 30 Days.
Scrum helps you navigate your way to the right product through increments of working software. You may create a holistic view of the future to gain funding, but understand and share that it can never be fully correct. It's a risk that always existed that Scrum is meant to help mitigate.

2. You undoubtedly have smart, creative team members that can work with your product owner to conceive of useful slivers of functionality they can design, code, test and deliver in the first sprint. Help put them in a position to do it themselves.

3. "How can I handle their idle time?". You shouldn't, they should. Get the team together and get them talking about the product and the backlogs. It's quite possible the team is not balanced. Something they can consider adjusting in the next sprint. Maybe they just don't yet know how to work in this new way. That will emerge over time, because this is definitely a different experience.

4. Sprint backlogs will always change, because they are the combination of what to build and /how/ to build it. Information on /how/ will always emerge that will potentially effect /what/ can be built. By making that promise transparency has been limited. As such, your PO can no longer make the most informed decisions. I don't think they will like that.

Hello.

1. I think trying to see the whole picture is different to designing the whole product and write a spec for every single feature. You can work with epics and if parts of them influence any PBI you are working on, then try to specify them as far as you need. Specify what you need, when you need it and don't let things you know out of your sight if the have influence.

2. Any working feature the team picks ;)

3. Unittests in my opinion are written directly after (or before) writing the code, or never, so involve them, when there is code, there is something to be tested.

4. Here I will answer with my own experience, a little different to what scrum says. Scrum does not forbid being Scrummaster and developer. But in my experience with those two roles, one will always loose, and it's most of the time the scrummaster. If you are in a truely agile team in an agile environment, than it is no problem put in any other cause your mission of "spreading the word of scrum" in the team and the whole environment, will be replaced with "producing value for the customer". But this is only my experience.

5. It will always happen that a feature will not meet the customer needs, but with scrum you find out after 2-4 weeks, and you maximum loose those weeks. With not finishing PBI's there is a clear way. Inform the PO that it wont be ready (buggy) and DON'T show it. SHow only Items that meet the definition of done. If something changed with the item (new insights brought you a better understanding) reestimate and put it back to the next sprint planning.

And in all cases talk to the team and encourage them to find a solution and improve their way of working.

Br,
Philipp

1. No, because Scrum works incrementally instead of using BDUF(Big Design Up Front) or BRUF(Big Requirements Up Front). Roman Pichlers works(blog, book) on Product Visioning should help here: http://www.romanpichler.com/blog/category/product-vision/

2. Aim for small features that are necessary for the product. Aim for features that will solicit feedback on the product vision. Roman's work on the "Minimum Viable Product" shoudl prove valuable here: http://www.romanpichler.com/blog/tag/minimal-viable-product/

3. If the testers and analysts are required to turn requirements into software, then it is *required* that they be on the Scrum team. Scrum is very specific on this point. In terms of idle time, my suggestion, without knowing any other context, would be to have them work on getting really good at ATDD, User Stories, and test automation. Since it sounds like you might have some weakness in the PO role (See #5 below for that), the analysts and testers can help to create "ready stories" in conjunction with the PO. The best practice with respect to ATDD is that tests are automated either before or in parallel with the coding effort. Good article on the "Definition of Ready" here: http://www.romanpichler.com/blog/tag/ready/

(Note that I have no relationship whatsoever with Roman -- I just highly respect his work and find it applicable to this topic)

I also have a relevant presentation on Acceptance and Story Testing Patterns here:
http://www.scrumcrazy.com/file/view/StoryTestingPatterns3.pdf/382870848…


4. No, I do not think you should rotate the SM role and neither does Ken Schwaber, the co-creator of Scrum. I could find the reference, but he essentially said that rotating the roles is a very sub-optimal situation and should only be done in circumstances where it cannot be avoided. Having said that, at the appropriate time, you can turn duties over to the Dev Team that are often done by the SM in a "beginner/Shu" level Scrum team. These include: grooming the product backlog, sprint burndowns(aka monitoring sprint progress), making sure the sprint backlog board is updated daily, facilitating the Daily Scrum. This should help offload some of the legwork of you as SM. Having said that, I would not begin to turn over that stuff until the team had 10 sprints or so under their belt.

5. This one I have some concerns about
a) Your boss is the PO. Has he been to PO training? Also, PO's are typically from a business part of an organization...What is the main reasons behind making your boss the PO? Even if he is the right person for the role, my next question would be: "How often can developers get an answer from your PO within 3 minutes?" -- This is a question I use to judge just how available and co-located a PO is. By co-located, I mean talking distance.
b) Why did you assure your boss that the Sprint Backlog would not change?
c) Bugs can be handled this way: http://www.scrumcrazy.com/bugs
d) Feature won't meet customer needs -- found out at end of sprint. First, see if you can get customers involved during the sprint so that won't happen. Second, if that's not possible, then add a new PBI/story on the backlog for any needed changes to the feature as delivered. Retrospect on how often this is occurring, and try to get it down to "fairly rare"

Hope this helps. I've tried to give you some quick answers, along with pointers to more detailed info. It really sounds like you are trying to do good Scrum, and that's the main reason I spent so much time on this post -- I like helping those who are taking a strong interest in doing excellent work. Best of luck to ya!

Hello again,

thank you very much for detailed answers. it took a while to digest all the information. I have further questions regarding your answers, hopefully I will reply individually.

Thanks again, regards
olamalam

Just a quick update,

We are starting for our product netmera (http://netmera.com) on 21th of Jan.
So far our product owner wasnt aware of who is busy with what, which feature will come when, no demo application about new fetures to show to customers, low productivity among the team, very hard to make changes etc.
When I'm assigned to the project, I noticed that scrum is what we need.

* I've prepared a product backlog with items prioritised from 1-6.
* We've done the sprint planning meeting with senior members and we broke down items with priority 1 and 2 into development tasks. And yes, we played poker, it really works.
* I've prepared the first sprint backlog (3 weeks) with all 1 priority items and I could fit some 2 priority items as well.
* I'll give a scrum training to the whole team on Tuesday and then people will pick the items from sprint backlog.
* I found this cool online tool to create burndown chart: http://www.burndownchart.nl/
* I've prepared the scrum board. It's empty now, it'll be full of post-its next week.
* Me and one of the senior members are planning to prepare test cases for each item next week (I guess normally I should let the team create those)

I'd appreciate if you let me know if I'm missing anything.

Thanks, regards
ilker

Hi Charles,

Thank you so much for your time, links and information you've provided.

Posted By Charles Bradley - Scrum Coach and Trainer on 08 Jan 2013 07:20 AM
1. No, because Scrum works incrementally instead of using BDUF(Big Design Up Front) or BRUF(Big Requirements Up Front). Roman Pichlers works(blog, book) on Product Visioning should help here: http://www.romanpichler.com/blog/category/product-vision/

Ok, when developing a new project, team shouldnt spend much time with the design of the whole system and create a big user requirement specifications. I've never seen that a project can be finished exactly the same as written in those documents anyway.
However, we will need to estimate roughly then, according to the product backlog.

2. Aim for small features that are necessary for the product. Aim for features that will solicit feedback on the product vision. Roman's work on the "Minimum Viable Product" shoudl prove valuable here: http://www.romanpichler.com/blog/tag/minimal-viable-product/

Yep, that makes sense. As written above, I'll aim for the login screens for instance. Or if its an integration project, I'll aim for receiving the data from outer system and storing in a DB for instance. Then the output of the sprint will be the content of these tables maybe. As I've written earlier, my first project as a scrum master will be with a product (netmera) so I wont have this problem.

3. If the testers and analysts are required to turn requirements into software, then it is *required* that they be on the Scrum team. Scrum is very specific on this point. In terms of idle time, my suggestion, without knowing any other context, would be to have them work on getting really good at ATDD, User Stories, and test automation. Since it sounds like you might have some weakness in the PO role (See #5 below for that), the analysts and testers can help to create "ready stories" in conjunction with the PO. The best practice with respect to ATDD is that tests are automated either before or in parallel with the coding effort. Good article on the "Definition of Ready" here: http://www.romanpichler.com/blog/tag/ready/

(Note that I have no relationship whatsoever with Roman -- I just highly respect his work and find it applicable to this topic)

I also have a relevant presentation on Acceptance and Story Testing Patterns here:
http://www.scrumcrazy.com/file/view/StoryTestingPatterns3.pdf/382870848…

Roman seems to be great guy indeed, too much reading. Now I have plenty of ducoments to read on my way to work :) As you may notice, I'm developing myself incrementally as well. I'm no expert of scrum but I didnt want to loose time until I become an expert. I'll learn with the team as well.

I'll have a scrum team of 10. 1 tester, 1 technical sales/analyist and 8 developers. I paired developers and I will ask the to analyse each others task and also do the first level tests of each others task. Tester will be busy with creating as many test cases as possible until development tasks are ready to be tested. Also she will be testing items from the previous sprint.
As for technical sales/analyist role, it's little bit complicated. He is responsible for creating videos, documents about the new features, announce them on social networks etc. and in order to do these, these features should be ready. So, most of the time he will be dealing with the items from the previous sprint + since he should know the features better than developers, he will help us with the analysis of the items of current sprint.

4. No, I do not think you should rotate the SM role and neither does Ken Schwaber, the co-creator of Scrum. I could find the reference, but he essentially said that rotating the roles is a very sub-optimal situation and should only be done in circumstances where it cannot be avoided. Having said that, at the appropriate time, you can turn duties over to the Dev Team that are often done by the SM in a "beginner/Shu" level Scrum team. These include: grooming the product backlog, sprint burndowns(aka monitoring sprint progress), making sure the sprint backlog board is updated daily, facilitating the Daily Scrum. This should help offload some of the legwork of you as SM. Having said that, I would not begin to turn over that stuff until the team had 10 sprints or so under their belt.

Ok, I'm convinced to stay as scrum master. I'll have one difficulty though. My boss is willing to assign me 2 more projects in very near future. Do you think that a SM should only be focused on a single scrum team?

BTW, I dont mind to be challenged, I enjoy it.

5. This one I have some concerns about
a) Your boss is the PO. Has he been to PO training? Also, PO's are typically from a business part of an organization...What is the main reasons behind making your boss the PO? Even if he is the right person for the role, my next question would be: "How often can developers get an answer from your PO within 3 minutes?" -- This is a question I use to judge just how available and co-located a PO is. By co-located, I mean talking distance.
b) Why did you assure your boss that the Sprint Backlog would not change?
c) Bugs can be handled this way: http://www.scrumcrazy.com/bugs
d) Feature won't meet customer needs -- found out at end of sprint. First, see if you can get customers involved during the sprint so that won't happen. Second, if that's not possible, then add a new PBI/story on the backlog for any needed changes to the feature as delivered. Retrospect on how often this is occurring, and try to get it down to "fairly rare"

a)
My boss has no idea what scrum is :) He will attend my scrum training this tuesday. (actually we have 2 bosses, one of them acts like an architect and the other one is more on the business side. Our PO is the second one). I think he should be PO since he know the product very well, he is the one in contct with customers, he knows which features can make the product more sellable etc.
Our organization is not huge, we are 30 people. And PO will be around most of the time. I can get answers in 20-30 mins in worst case.

b) Becasu I think that it shouldnt. From my early scrum experience, Sprint backlog is frozen during the spring. No?

c) Thanks for the link.
d) agreed.

Hope this helps. I've tried to give you some quick answers, along with pointers to more detailed info. It really sounds like you are trying to do good Scrum, and that's the main reason I spent so much time on this post -- I like helping those who are taking a strong interest in doing excellent work. Best of luck to ya!

Honestly, it was very helpful. Thanks again.
As I've read somewhere, in order to achive success with scrum, you shouldnt customise scrum. Use it as it is. So this is why I'm trying to do it good. Since now you have the link of our product, you will be able to see if I did an excellent work or not :)

Hi Philip,

Posted By Philipp Eisbacher on 07 Jan 2013 12:10 PM
Hello.

1. I think trying to see the whole picture is different to designing the whole product and write a spec for every single feature. You can work with epics and if parts of them influence any PBI you are working on, then try to specify them as far as you need. Specify what you need, when you need it and don't let things you know out of your sight if the have influence.

2. Any working feature the team picks ;)

Yep, agreed. I'll see how it works once I'll have to develop brand new project. At least now I have an idea.

3. Unittests in my opinion are written directly after (or before) writing the code, or never, so involve them, when there is code, there is something to be tested.

It is relatively harder to plan his/her time in the beggining of the sprint but as I've written in my previous post, I'll assign some tasks like writing test cases etc.

4. Here I will answer with my own experience, a little different to what scrum says. Scrum does not forbid being Scrummaster and developer. But in my experience with those two roles, one will always loose, and it's most of the time the scrummaster. If you are in a truely agile team in an agile environment, than it is no problem put in any other cause your mission of "spreading the word of scrum" in the team and the whole environment, will be replaced with "producing value for the customer". But this is only my experience.

I'm not going to change SM role in near future.

5. It will always happen that a feature will not meet the customer needs, but with scrum you find out after 2-4 weeks, and you maximum loose those weeks. With not finishing PBI's there is a clear way. Inform the PO that it wont be ready (buggy) and DON'T show it. SHow only Items that meet the definition of done. If something changed with the item (new insights brought you a better understanding) reestimate and put it back to the next sprint planning.

And in all cases talk to the team and encourage them to find a solution and improve their way of working.

Br,
Philipp

That's very true.

Thanks a lot!

ilker