Scrum Training (1/2)

Here are some of my notes from “Working on a Scrum Team” training by Kenny Rubin.

The Agile Manifesto

Individual and interations over process and tools
Working software over Comprehensive documentation
Customer collaboration over contract negotiation. (note: avoid hostile situations and the negotiation overhead)
Responding to change over following a plan

Three most important words in Agile is “inspect and adapt”.
See also Agile Manifesto

Lean Principles

Eliminate Waste
Amplified Learning
Leave option open as long as possible (note: This is motivated by the expectation that we will have more and better information at the last moment and it is the best tie to make a decision.)
Deliver as fast as possible
Empower the Team
Build integrity in (note: testing during development.)
See the whole (note: An example of approach this is to bring a documentation person into a beginning phase of a project to write user documenation on high level over view. If the team can do this, this shows that the team has a good understanding of of the whole project.)

An Agile Iteration

In an iteration, the team attampt to deliver what customer(s) asked for. What customer(s) asked for may or may not be what they want. If the customer(s) do not want what the team delivered at end of an iteration, the customer(s) can re-prioritize the re-work for the next iteration.
In the training room, some people expressed that they received high level requirements. The team often needs to break-down the reqirements into sub-projects or individual stories for Agile iterations.
For teams that work on multiple projects at the same time, see notes at a later section.

Scrum

See also Yahoo Groups
Product backlog: Owned by product owner. Eac requirement are sized, prioritized by value, cost, knowledge and risk.
Sprint planning meeting: Product owner and team produce sprint backlog together.
Sprint backlog: Contains tasks for the sprint
Sprint: The team commits to delivering some amount of functionality. Product is potentially shippable after every sprint. The product owner/customers commits to leave priorities alone during the sprint.
Requirement can be incomplete and our understanding of them is refined during the sprint. So the team will have to judge on case-by-case basis to accept changes during a sprint or not.
Sometimes, if the team expects a constant stream of unexpected urgent tasks, the team can pre-allocate a certain amount of time for this type of activities into the scrum estimation.
In extreme circumstance, a sprint might abnormally terminated if change can not be kept out of a sprint or if there is no value to continue a sprint.
Supplement written documentation with conversations.

Product owner and srum master should be two different people, at least the role should not be on the same person.

The ScrumMaster

Alternate names: Servant Leader, Sheepdog
Some teams may have a ScrumMaster that has a secondary role of both ScrumMaster and an individual contributor on the same team. This arragement can work in some situations.

The Team

Self organizing and self managing
After several months, most team feel the Scrum practice is getting easier. At around 9th month, the team may encounter new challenges such as seeding Scrum practices to other teams.

Team Size

Fungible Resource

Definition
Team cross pollination can help knowledge transfer at the cost of time/energy for the team into performing stage. Historical velocity data will be nullified and need to be re-established.

Agile Planning

For feature driven release, which can be done by establishing a cut-off on the backlog. This means release date becomes variable or estimated with a range.
For date driven release, the features becomes variable.
If there are dependencies among stories, additional planning needed, specifically rolling lookahead planning. It basically assist planning on when stories can start i.e. place in which iteration’s backlog.
Sprint/iteration 0 – Some teams starts with 0 to setup infrastructure or create the initial backlog.
Some teams has a finalization sprint/iteration in preparation for a release.
During sprint/iteration 1, the team may plan and estimate tasks for the next sprint/iteration.
Work unit accounting should not use a partial credit technique to keep the planning/management simple. Although this might impact velocity for a particular sprint/iteration, it will not have a significant impact in the long run on average velocity.
“it’s better to be roughly right than precisely wrong.” — John Maynard Keynes
Precision on product backlog’s estimation doesn’t need to be as precise as sprint backlog.
Avoid task buffering. Instead, use schedule buffering. i.e. perhaps add a buffer iteration before the major release.

Release Planning

Theme is a collection of stories. For the next release, what is the theme the product owner want to focus on?
Priority poker is an exercise that allows each participants to priortize themes by voting with poker chips. Re-votes might be necessary if there are themes/stories that are unpopular, required for the next release, and did not receive enough votes in a prior vote.
Crises work should be consistantly counted or not counted during planning. So velocity calculation stabilize. Velocity should not be an employee performance metric. Teams should not do velocity-driven planning also. See explanation on this topic tomorrow.

Agile Requirements

Before the first sprint/iteration starts, several things has to happen, such as project inception (story writing, prototyping, etc.).
A goal is to have the least amount of requirement needed to be successful. (Having the most amount of requirements is equivalent to waterfall model.)
Not all requirements need to be at the same level details initially. “Strive to describe items as briefly as possible”
Sometimes requirements were not well written and not testable. Tomorrow’s notes will cover this topic.
The product owner team should review the work done throughout the sprint/iteration soon after the task done and not wait until end of the iteration.

Dave's Blogs