Posted by jc-Qualitystreet on 2010/08/11
One of the first differences observed with Agile is the way we estimate the size and duration of an IT project.
The entire team is made responsible for the estimate of the product Backlog (the list of all functionality desired in the product). Indeed, the team is invited to estimate collectively this list of valuable items that will require his work.
Scrum teams use Story Points and Planning Poker for this activity.
- Story Points represent a measurement of the effort required by a team to implement a Story.
- Planning Poker is an effective (and funny) way to assign collectively story points to user stories on the product backlog. It is a special card game based on the Fibonacci sequence. The idea is to pick a representative story and assign it a point value, then estimate the other stories relative to this standard (consensus must be reached for each user story)
Planning Poker Deck
Collective intelligence is the pillar of this new way to estimate … an effective team-based estimation technique but not so natural at first. Relative size and consensus are not so easy for the teams new to agile.
The problem:
Teams often lose the thread of their estimates. They have difficulty in comparing or lack of benchmarks.
An answer:
Use a visual display of the planning poker values in columns, and place the user stories in the appropriate column during the activity.
Visual display of the estimates
Benefits:
- It is an effective form of visual management
- It facilitates comparison and triangulation
- It reinforces the concept of relative size (effort)
- It reinforces the idea that result is not frozen during the activity: change is easy t!
Posted by jc-Qualitystreet on 2010/03/30
Agile Coach vs ScrumMaster: it is sometimes a bit blurry … probably because the ScrumMaster acts sometimes as an agile coach, using coaching techniques and probably because the Agile coach is sometimes asked to play the role of ScrumMaster in Scrum projects.
But according to me: “The ScrumMaster is not an Agile Coach” … here are some elements of comparison:
|
AGILE COACH
|
ScrumMaster
|
| Mission |
High variability. Never the same.
For a person and / or a Team and /or an Organization
A strong clarification of the objectives and a precise analysis of the context are required.
For this journey toward agility, concrete and measurable result should be defined. |
Little variability. Often the same
For the team
Objectives are usually unambiguous, related to a well defined role description:
- Ensuring that the team is fully functional and productive,
- Ensuring that the Scrum process is followed in terms of values, practices and rules
- Enabling close collaboration
- Protecting the team,
- Removing Impediments
|
| Scope |
Agility (broader) and Change |
Scrum |
| Link with the Project |
The agile coach is not involved in the project (independent) |
The ScrumMaster is involved in the project |
| Link with the team |
Not part of the team
Does not protect the team |
With the team daily
Protects the team |
| Activity - Presence |
Variable and not continuous depending on the context and needs. Stronger presence at the beginning of the mission, less thereafter. The Coach is looking for the autonomy of his client … |
Continuous. Throughout the project period. |
| Training |
Trained in methods, roles and Agile practices.
Trained in coaching (certified or not)
Good knowledge of IT projects life cycles, roles, actors and activities
Basic knowledge of psychology |
Trained in the role of ScrumMaster (certified or not) |
| Experience in agility (depth … Years of experience.) |
Required |
Not necessary |
| Experience in agility (width … Implementation in various contexts, with multiple teams) |
Required |
Not necessary |
| Acts as a Trainer |
+ + + |
No |
| Acts as a Facilitator |
+ + |
+ + + |
| Acts as a Mentor |
+ + + |
+ |
| Acts as a Coach |
+ + + |
+ |
| Acts as a Consultant |
+ |
No |
| Is the agent of change |
+ + + |
+ |
Scale: +++ (Yes Very Much) ; ++ (Yes Much) ; + (Yes Little) ; No
It’s my Vision, what’s yours ?
Posted by jc-Qualitystreet on 2009/11/13
Christmas is coming and kids know it. This is what happened to me last weekend …
My kids “Dad … Dad for Christmas … can we play the sticky notes game ”
Me: “Okay kids, but this time we’re going to change the rules”
In one year, I had the time to improve the process :) even if the constraints are almost the same:
- Santa Claus is very busy
- His sledge is not expandable
- The deadlines are tight
- The delivery date cannot be moved
In addition, my kids as good Product Owners have understood two important things making them realize the importance of priorities:
- You cannot have everything (even if you always want more),
- Being good (or not) can potentially impact on what you’d receive
Scrum / XP from … Home!
Or how we set priorities to write the letter to Santa Claus 
Step1 : Brainstorming, data collection and workshops
Passionate reading for weeks, intensive research from several sources, and interviews with the little brother to finally cut in the magazines the images of the toys they like
Step 2: Backlog Initialization
The images are cut. In case of several kids, ask them to place their images in an envelope. Use one envelope by child then one image by sticky note. The backlog is initiated.
Step 3: Backlog Prioritization
Notes are laid on the ground. Ask the kids to rank in order of preference by placing on the top toys they want most, the most important to them…
… ..
….
Step 4: Backlog Display
Notes are now prioritized on the ground. We had to find a wall or a door to display them vertically (visual management …).
My daughter’s wall (not very reasonable):
My son’s wall (moderate …)
Retrospective: We had a good time and kids were very happy !
My wife and I’ll take care of the estimation (points/ euros)
