Monday, 10 September 2012

Scrum for SharePoint - Part 2

See Part 1

Technology: I am using Team Foundation Server 2012 Release Candidate.  I believe the best tools for the scrum team are offered through Visual Studio. VS 2012 has all the features and VS2010 can't do specific tasks such as create projects however I've found using VS2010 to work well.  The template used in TFS is the Visual Studio Scrum 2.0 template.   Also see

Ways to work for TFS:  VS has the most comprehensive feature set for working with TFS 2012.  You can also use the TFS web UI, the SharePoint Foundation UI that is hooked up to TFS or excel and then import the data.

Creating PBI's: The screen shots use TFS2012 RC & VS2010.  I have annotated the screenshot to help with input of PBI's.  Not the priority is set from 1-1000 (default is 1000 which is the lowest priority).  I like to use Mike Cohan's planning poker (uses a relative Fibonacci sequence number to assign relative effort weight).  The scrum team vote on estimated effort after an understanding of the user story is complete.

The scrum master has to accept the PBI and for me to do this I need 3 pieces of information namely: the user story, acceptance criteria & additional detail short clear information such as an annotated Balsamiq mock-up.  Obviously the product owner  may negate the need for additional information but often they need to get this information from someone else in the business and I find mock-ups invaluable for clarifying to all people visual requirements.

Acceptance criteria is needed for each PBI.  This would be good to have in the Sprint planning meetings.  This is the format I recommend (gherkin language).

An example I have is
Scenario: Employee requests leave
  Given an employee has sufficient leave available in the year
  When the employee schedules leave (holiday)
  Then the employee is informed his request is valid and his manager is informed of the request.

Acceptance Criteria – “What is Acceptance Criteria? Put simply, it's the criteria that defines what "Done" means for each PBI. Acceptance Criteria is critical to the success of a Scrum team, as it becomes the handshake between the Product Owner and the team -- it helps define what the team is committing to.”
"Pre-established standards or requirements a product or project must meet" Google's definition of acceptance criteria.
Normally acceptance criteria focuses on functional user stories but you also need to cover NFR's such as performance.  Negative acceptance criteria is often overlooked when creating AC's and do the AC's before development starts, you can always change them later.
An alternative to Gherkin for writing the acceptance criteria is to use checklists to ensure the User Story does what the business stakeholder wants and the developer has developed it correctly.

(Story Board)

The TFS 2012 Scrum template provides a good overview of the current sprint.  Team favorites are dropped from TFS queries to provide useful insights into the project.

Daily Stand-up (max 15 min):  I like to perform these at about 10:00 every day in the morning.  Each person tells the group: done/achieved in the past 24 hrs, what they are doing in the next 24 hours and brings up any blockers/obstacles/impediments.  I like to take notes as the scrum master and as the team falls into place.  I let team members run the daily stand-up scrum meeting in random turns once we all know how to do them and it seems to work well with communications in the team and I take summarized notes and I use the format:  Date, Time, Attendees, Each attendee summary & general meeting notes:  e.g. Adam and Paul were late for the meeting, blockers were not recorded, Kanban board was not updated....
Rules: Start at 10:00, be concise (part items that are taking to long and get the people to talk after the meeting), all participants to stick to the format: last day, today and blockers.  It always ends at 10:15 and leave the area.  Listen to the appoint meeting scrum master and they need to stop ongoing discussions.

Demo Meetings:  Date, time, attendees & roles, problems & suggestions.

Sprint Review Meeting: Done at the end of a sprint cycle after the sprint is over.  Ensure each PBI is reviewed.  Often used with demos to validate each PBI and this allows the Product Owner to evaluate the PBI's fulfillment and make changes if necessary.

Sprint Retrospective Meeting: Optional meeting to identify improvements that can be made.  I use this meeting after the Sprint Review at the end of the 1st 2 or 3 sprints and then only periodically as the project progresses.  Tip: Use the format: Glad, sad, bad game. for managing Retrospectives.  An alternative is to the approach: What went well, What didn't and What needs to happen.

Sprint Planning Meeting:  Have a sprint goal.  Done at the start of the sprint cycle.  The scrum team and the product owner identify items from the product backlog to go into the sprint.    the last part of the meeting is to create a sprint backlog to implement each item selected from the product backlog.

Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2 (This Post)
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1


Paul Beck said...

Azure works well for getting EPIC requirements

Post a Comment