I have been reading lots of discussions around the Scrum Alliance and its certification process. Does taking a two class make you a good Scrum masters? For an answer to this question, I asked some of my friends who have been great scrum masters.

The general opinion was that while the CSM class does give the basics of Scrum, it completely misses the ball on the “Human factor” involved in being a good Scrum master. Some of the best scrum masters seen are not certified but certification does help. The great thing about the CSM class is the interaction with others much less the certification part. Many times scrum masters learn by doing trial and error on Scrum basics and in doing so they end up causing a lot of damage to the team.

By going to a CSM or for that matter any training class , the interaction with the instructor and others in the class will get you going on the basics. I am an Agile coach and often play the role a scrum master. The toughest part in being a scrum master is not Scrum, it is being aware of what to do and what not to do in a team.

Every time I take the role of a Scrum master and coach Scrum masters, I always tell them not to apply the same rule to every team. Each team you will facilitate is different. As far as certifications go they are a nice to have tool , but that should certainly be not the criteria to hire a scrum master.

Along with it try to see if they pass the CFROC Test.

Are they committed to the team, Can the keep the focus on Scrum and distance themselves from the politics, Can they respect themselves and thier team members,
Are they open enough to help the team with whatever the team needs without taking any sides, Are they courageous enough to stand up to the team and protect them.

BTW this is spoken about in the CSM, but leaning and doing are two different things.

Here is an example of one such statement

“ As scrum masters of , we are servant masters enabling teams to deliver business value in the software we develop, protecting teams from external interferences, resolving impediments that teams have and coach teams in better ways of achieving software agility”

Our core values are

- Passive listening
- Respect
- Courage to speak up
- Be compassionate and help team member be better at what they do.
- Always find new ways to improve.
- Remove impediments that team members have.

Teams use different sizing techniques

T Shirt Sizing

X Small, Small , Medium , Large , Xtra Large

or

Coffee Sizing

Small, Tall, Grande

You can pick any sizing technique. Make up one if needed.

This is mainly done as we as humans and as managers are better at abstract terms. If we use hours as a way to size stories,then the managers in the room have questions, teams dont immediately feel comfortable with hours.

Sizing keeps the planning meeting at a fast pace.

A general measure you can use  for T Shirt sizing is how many days it take to complete a story

Small story –  1-3 days

Medium – 3- 5 days

Large – 5 – 7 days

X Large > 10 days

In order to convert a story size to a number you can use either factorial, Fibonacci or Squares.

Sizing Techniques

If in  a sprint your team does two small stories and two medium  then your velocity is 9 * 2 + 4 * 2 = 26 ( if you are following the squares techique). Square is simple and works quite well.

You can have stories that span multiple sprints, that may not make it to production. This may be part of a larger EPIC story. The goal is to work on it every sprint. We have seen many instances where the product owner decided to ship the story half way through that process, as they see see that what is developed so far is not complete, but is good enough to ship.

Teams take a while to form and norm. They also make a lot of mistakes and tend to work a lot harder in the beginning.  Remember the Agile priciple

Simplicity–the art of maximizing the amount
of work not done–is essential

Teams take a while to master this. Once they have this and resoved team forming, norming, that would be a good time to start comparing them with others.

One of the main tenets of Scrum is “Sustainable pace”. Scrum teaams are able to get to this sustainable pace as they get really good at delivering something in a short span of time ie, 2 or three weeks.

Velocity cannot be precicted well if the Sprint length changes. If you think changing 2 to three weeks is going to help you, you are mistaken. The team will only end up signing of for more work than they normally would. Hence the problem has really not gone away.

When working with stories from a product backlog especially during release planning, Write all the epic stories ( the main use cases ) and instead of stank ranking them numerically, apply the

• Must Have,
• Should Have
• Could Have
• Wont Have

rule to each story . i.e. ask the product manager to write a M S C or W in front of every story. Sometimes product owners find it tough to apply numbers but a grouping like this is much easier for a first pass.

Product owner is the the hub of the scrum team. They can make or break the team. The reason for this is that they hold the key to the story box. They are the visionaries ( sort of a product manager). At times they are also proxying for others. Many scrum projects fail solely because the product owner did not perform his role well.

The important functions among others of a product owner in no particular order are:

1. Own the product backlog and in doing so the check book.
2. Be the sole voice for requirements that the team can trust.
3. Be the mediator to other interested parties in the organization and allow other stake holders to make thier case
4. Communicate with the management on the status of the project.
5. Be the main anchor in a sprint planning meeting.
6. Prepare the backlog every sprint for the next sprint or so. Capture lots of detail for the upcoming stories while thinking a bit about the stories for future sprints.
7. Be able to articulate what it would take for a developer so that he /she can accept the story as done.
8. Do bug triaging.
9. Train the users as the visionary of the product.

This is a simple document which can be changed every iteration or sprint or necessary. Anything goes here that all developers agree.

Common things added in this list are:

1) Core time that the team members will be present. In case of a distributed team this would define the core overlap time the distributed teams will meet

2) Time of stand up.

3) How much pairing hours are considered good. An ideal pairing day could consist of any where from 2 – 6 pairing hours for example

This document is visited every interation and changes are made. This is one of the visible indicators that should be in the area where the teams are working.

Here is an actual example of one such document from a highly productive scrum team

1. Tell the Truth.
2. Use the Impediment Backlog for blocking issues
3. Address any issues to the correct party (at the right time).
4. Meetings: Be on time, end on time, have an agenda
5. Communicate individual schedule
6. Use sticky note on monitor, email, phone call, etc.
7. Update backlog before SCRUM daily
8. Be present for core hours: 10:00AM – 5:00PM
9. Communication – to the best of our ability
10. Publish phone numbers & Calendar
11. SCRUM is at 11:00AM Pacific Time
12. If unavailable for SCRUM, communicate status
13. Test Driven Development is a requirement for the project.
14. Pairing or code reviews are required for any shipping code
15. Part of requirements for DONE criteria
16. When pairing, turn off distractions (email, IM)
17. Define and adhere to DONE criteria for stories
18. Record Accurate (actual) hours
19. Define and adhere to Version Control rules
20. Don’t break the CI build!

In simple terms its a number that tells the team how hard the story is.

In most cases a story point range is

1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large

It is a relative term and does not directly co relate to actual hours . Since story points have no relevance to actual hours, it makes it easy for scrum teams to think abstract about the effort required to complete a story.

This also creates a lot of confusion as most scrum masters who come from a PMP background relate this immediately to hours.

Story points do give some indication of how much time time was spent in a sprint.

Example lets say at the end of a 10 day sprint a team of 4 covers 40 story points.

10 days = 10 * 8 working hours = 80 hours. = 320 total hours as there are 4 developers.

That equated to 160 pairing hours.

160 divided by 40 =  4 hours pair hours per story point.

Velocity is a measurement of how much the team gets done in an iteration ( called as Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is planned.

In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

Examples are 1, 2, 4, 8 , 16

5, 10 15 and so on.

A story depending on its complexity is given certain story points. So if the team does 6 stories that are 8 story points that iteration , the teams velocity is 48 story points.

This is a document that basically says what needs to happen for the sprint ( iteration ) to be called Done. There are at least three types of Definitions of done.

Story Definition of done

What must happen for the story to be marked as complete.

An example Story definition of done would look like this.

1. All story should have automated acceptance test.
2. The story should have working code supported by unit test that provide around 60 – 70 percent coverage.
3. The story should have well defined acceptance criteria.
4. The code must have been written as a pair or should be code reviewed.
5. Code must be completely checked in to the source control system and the build should pass with all the automated tests running.
6. The product owner must accept the story.

Sprint Definition of done:

1. Product owner should have defined a sprint goal.
2. All stories completed for the spring must be accepted by the product owner
3. All the automated acceptance tests should be running for the stories in the sprint.
4. All code should have been pair progrmmed or must have gone thorough a code review process.
5. If there is a database involved, the database scripts must have been automated and tested.

Release Definition of done

1. Product is deployed to the test box and makes it to staging
2. Product has a formal release date.
3. There are deployment documents for the release
4. Training manuals are available for users.
5. All stories for the release are completed and accepted.
6. The release does not have any level one bugs.