Tuesday, March 31, 2009

You’re either on the team or you’re not…

Just a little rant today:


Scrum has 3 roles.  Scrum Master, Product Owner, and the Team.  I believe in a team of doers and performers (probably the same thing). 


I, in general, don’t believe in putting a data modeler on a team, or an architect on a team, or any specialized role on a team.  It’s not to say I don’t believe in having a data modeler or architect on the team, as long as they can view themselves as a member of the team willing to do work and get work done.


I believe the team needs a team data modeler if the team says, “These data relationships are pretty complex, we really do need a data modeler”, then we start talking about a data modeler (or architect, or whatever).  However, in many cases, the team members can really model their own data or architect their own systems.


Often, we use a DBA service, or operations service.  They provide a service to the team, but not a part of the team.


There may be some exceptions to the rule.  When you want to create an organizational consistency, you may have an enterprise architect or data architect, but they usually work with the team as a guide or provide service.  If you’re on the team, you’re on the team, skin in and all.


Anyways, just a bit of a minor rant today, no real coherent thought to it.

Wednesday, March 18, 2009

Using planning poker to ensure common understanding


One of the techniques that many Agilists have been embracing is using planning poker to help the team estimate and plan for an iteration. The focus of today’s blog is that one of the nice benefits of planning poker is helping ensure a common understanding of the work (story) at a team level.

Brief Introduction to Planning Poker


Planning poker is generally used during the team iteration planning meeting to help the team create estimates for stories (feature requests). Each team member has as set of cards that are numbered based on a modified Fibonacci sequence (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity).


After each story is presented to the team, there may be a few questions regarding the story. The time spent asking and addressing these questions should be kept as brief as possible. At this point, this is not a design discussion, the questions should only relate to helping the team member form a rough order of magnitude estimate.


After the story is presented, all team members display their cards simultaneously. Once all the estimates are shown, the team can determine if there is a general consensus or agreement to the estimate for the story.

Common Understanding


If all of the estimates are roughly in the same neighborhood, then the team is ok. You can optionally ask the highest and lowest estimates on what their thoughts are, but if they are in the same ballpark as the rest of the team, it is usually relatively easy to come to an agreement.

Example, if the ranges are a 3, a couple of 5s and several 8s, not a big deal. Have the 3 explain their thought and you’ll find they’re probably willing to go up on their estimate.


Note when everyone in the same ballpark, do NOT spend a lot of time discussing the story, you’re done estimating the story, go on to estimating the next story (or tasking the story, if your team tasks after each story, which I would NOT recommend).


However, if there is a large gap in estimates, this is where you get the good stuff. Say most of the team is around a 5, but one person has a 20, then something’s going on. Either the 20 does not have a correct understanding of the story (or what it takes to implement the story), or the 20 knows something the others do not. Either way, this requires discussion.


Examples 1 – technical implementation:

The story is “implement role based security model”. Most of the team throws an 8, however one person throws a 40. Discussion is held and the people throwing the 8 believe they can leverage an existing security model the company has. However, the 40 knows that the legacy security model is outdated and does not come close to supporting the needs of this project. The ensuing discussion helps bring this to light and the team re-throws based on this new knowledge.


Example 2 – Story understanding:

The story is “Display Custom Images in System”. Several of the developers throw a 100 and the business analysts throw an 8. Each is surprised at the other’s estimates. During the discussion, turns out the developers thought that the system needed the ability to actually create and save images while the true requirement was that the system only needed to display an image from a specified location.


The key point of this blog is that using this technique should allow the team to quickly breeze through estimating stories where there is a general consensus on the size of the story and ensuring there is a common understanding in situations where there is a large gap in estimates.


(Note that the common understanding is just one of the benefits of planning poker. There are also major benefits in terms of velocity and using velocity to help plan team capacity, but more on that in a future blog.)

Monday, March 2, 2009

Scrum Artifacts

I was recently asked to put together a list of Scrum artifacts, so I figured that this would be a good topic for my latest blog entry. Some of this will just be a Scrum 101 refresher for those familiar with Scrum, but this may be useful for many.

A couple of notes:

· The list below represents a possible/typical implementation of Scrum. One does not have to follow these exact items to implement Scrum.

· Many of the items described below are implementation details of Scrum, but not specific artifacts prescribed by Scrum

In Ken Schwaber’s Agile Project Management with Scrum, the only items he has listed as Scrum Artifacts are the Product Backlog, the Sprint (Iteration) Backlog, and Increments of Potentially Shippable Product Functionality.

· And yes, I know, many items on my list are not really artifacts. To make things easier artifacts presented in black, general concepts in blue, and meetings in red.


Epics / User Stories / Tasks

User Stories – A feature that can be estimated.

Epic – A feature that cannot be reasonably estimated due to its complexity, scope or number of unknown issues.

Tasks – The work needed to complete a User Story.

Epics can usually be broken down into User Stories. User Stories can be broken down into Tasks.


Product Backlog – A list of the Epics and User Stories for the entire Project / Product. This list is prioritized by the Product Owner.

Sprint Backlog – A list of the Epics, User Stories, and Tasks that the team has committed to completing for the current iteration. This is created during the Iteration Planning Meeting.

Story Points – Units of estimation for User Stories. Usually based on a modified Fibonacci sequence.

Planning Poker – A method of estimation used in Iteration Planning. Each team member is given a set of card representing story points. For each user story, team members display a card representing their estimates. The team discusses the results and comes to a consensus on the estimation.

Iteration Planning Meeting – At the beginning of each iteration, the Scrum team meets to plan work for the iteration. The first part of the meeting involves the team working with the Product Owner in reviewing the prioritized Product Backlog and putting Story Points for each User Story. The team then commits to a certain number of User Stories for the iteration. The second portion of the iteration is typically used by the team to create a list of Tasks for each User Story in the iteration.


Project Board – This can be a physical board, a virtual board, or both. The board is usually placed in a visible location and presents the status of the iteration (and sometimes the entire project). The board usually contains an area for Work in Waiting, Work In Progress, Completed Work, and Verified Work. Other items that can be shown on the board include (but not limited to) a team calendar, burn down charts, and list of impediments.

Daily Scrum Meeting – A brief (15 minute) daily STAND UP meeting in which each team member gives a brief status up. This typically is limited to:

· What have I done since the last Scrum meeting.

· What I am planning to do today.

· List any blockers/impediments I have

· List any items I have ready for review

This meeting is typically held in front of the Project Board and the team members should update their tasks on the board during the meeting. Only team members should present during the meeting and all team members (barring physical considerations, such as a bad back or being very pregnant) should be standing the entire meeting. Standing meetings tend to not go very long.

Iteration Burn Down Chart – A graph displaying the amount of work completed and amount of work remaining for an iteration.

Project Burn Down Chart – A graph displaying work completed and work remaining in the project.

Team Velocity – The amount of story points a team has completed or can complete in an iteration.


Iteration Review Meeting – Held at the end of an iteration, the Iteration Review allows the Product Owner, and potentially stakeholders and other interested parties, to review the deliverables for the iteration. All deliverables should be fully tested, defect free, ready to ship increments of functionality.

Team Retrospective Meeting – Held at the end of an iteration, the retrospective meeting typically allows the team members to discuss what has been working well, what has not been working well, and discuss any ideas for improvements or changes to the process.