Scrum for SharePoint - Part 1 Introduction

Overview: Scrum is an Agile methodology that is useful for SharePoint projects as it allows for discovery/refinements of requirements as opposed to formally knowing all the functional requirements of a system upfront.  Each project lends itself to specific methodologies however, an Agile approach is often more suitable for SharePoint projects.  For larger, more formal projects I like MSF but traditional SDLC methodology run projects also work well.  Scrum is one Agile methodology and probably the most commonly used.  As with all projects I recommend following a methodology but lend from other and take out what isn't working to get the optimal process.

Scrum for Dummies:  Scrum consists of 3 types of team roles: the product owner/s, scrum master and the rest are team members.  Tam sizes should be less than 7-8 people (if bigger use scrum of scrums).
1.) The Product Owner is responsible for creating user stories.  These are specified in the form: As the <role> , I want to <feature> so that <benefit>.

2.) From the User stories I create Product Backlog Items (PBI's), Scrum is broken up into sprints (usually 2-4 weeks).  The sprint kicks off with a Sprint planning meeting that involves the entire team.  PBI's are broken down into tasks, tests and bugs.  During the sprint planning, the team members commit (renamed to forecasting in 2016) to the PBI's in the sprint and creates a "Sprint Goal".  I usually set apart 3-4 hrs to complete the Sprint Planning session at the start of each sprint.

3.) Daily scrum meeting takes 15 minutes facilitated by the scrum master.  Each team member states what they accomplished in the last day, what they will be working on in the next day and any blockers.  When the team members start a discussion, shelve it and they can have a separate meeting outside the scrum to avoid over running on the scrum meeting.  Do scrum meetings standing it helps make the sprint/team finish on time.

4.) At the end of each sprint, there must be a potential deployment.  Hold a scrum retrospective, this is to work out the team velocity (are the PBI's and features being achieved) and work out how productivity can be improved.

5.) Documentation:  Scrum is not document intensive but aims to get features right not finish at a specific point.  The documents generated by scrum are:

5.1) User Stories and corresponding Acceptance Criteria

5.2) Meetings (Daily scrum minutes/decisions, sprint planning agreements/outcomes & retrospective minutes)

5.3) Whiteboards (architecture diagrams and user story refinement)

5.4) TFS recorded data 

5.5) Communications (emails about decisions, supporting information, this could also include pptx from presentations, user reviews).

TFS:

• SharePoint has a lot out of the box and using Scrum allows for better technical decisions whereby team members often identify OOTB solutions which hopefully eradicates the common developer mentality of using .NET to do existing SP functionality.
• There are Templates for Scrum download and base your project off them.
• Microsoft offer a great free services called TFSPreview (http://www.tfspreview.com/) which is a SaaS offering TFS 2010, doesn't have all the features but it is amazing and best of all it has a built in Scrum template so I'd always start with this and if you feel you are being to restricted you can always go for a on premises option. VSTS (cloud service) is the current name for TFS preview Oct 2017.

See Part 2 ...

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

DevOps User Stories