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.