Wednesday 12 September 2012

Switching version settings in a document library

Overview:  I got asked a question on Document libraries which is rather obvious but I needed to check this out.  If a Document Library is set to use "Major and Minor Versions" what happens to the minor versions when you set it to only use "Major Versions".  And the answer is... Nothing.  The historic versions work as they previously did (while under the minor and major verions), when the documents are edited they will automatically now only use major versions in SharePoint.

 

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 http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV212

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.  Optional. Free tool to use for planning poker   Try this, a friend of mine built this while playing around for Scrum Poker Planning. 

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.  Lastly, ensure that the team understand INVEST principles for  (Independent, Negotiable, Valuable, Estimat-able, Small, and Testable) for each User Story/Requirement.

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).
Scenario:
  Given
  When
  Then

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.”  http://www.nomad8.com/files/acceptance_criteria.php
"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.


Key Meetings:

1. Daily Stand-up (max 15 minutes):  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.

2. Demo Meetings:  Date, time, attendees & roles, problems & suggestions.  Do at the end of sprint, tend to be 30 minutes to 90 minutes per demo each sprint. 

3. 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.  Important but can be skipped by the whole team as long as the PO does it and is happy.

4. 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.  https://app.scatterspoke.com for managing Retrospectives.  An alternative is to the approach: What went well, What didn't and What needs to happen.


I've seen many different formats for running retrospectives, and a good default option for me is "mad, glad, sad". I also like the Danish baking Retrospective that I saw recently.  
Azure Devops Danish Baking Retrospective Board

A nice feature I was shown recently was to "Include a Team Assessment".  I'd use it every 3-4 sprints assuming we are using 2 week sprints, the results are a great indicator of confidence and the teams position.
Team Assessment in DevOps Retro board 

5. 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.  I also like to have a grooming of stories in the previous sprint to ensure the whole team know what is likely to come along and tech can feedback to the PO/stakeholders.

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