If you have multiple scrum masters in your organization, it will be good exercise to come up with a charter for your group.

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.

ike Cohn talks a  lot about this in his book Agile Estimation and Planning. You can use any measure to size stories.

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.

Managers , take it easy. In many organizations there is an urgency to measure, look at numbers as they move to scrum within the first two sprints. As a general guideline, do not take too much notice of the statistics for four or five sprints.

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.

This question comes up a lot in new scrum teams. The adjustment from a couple of months to two weeks is very tough indeed. Generally speaking do not keep changing the sprint length. One Sprint two weeks, the next three weeks etc.

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.

MoSCoW rule

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.

Unquestionably this is the product owner.

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.

By definition an agile team has a high amount of daily interaction. This brings out a need to establish some common set of rules that all team members abide by.

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!

Story point is a random measure used by Scrum teams. This is used to measure the effort required to implement a story.

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.

 = Number of total story points / One iteration

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 applies to the Scrum management process.

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.