The following are three SharePoint Online Agile methods:
Implementing SharePoint Using Agile Methodology: Agile in SharePoint Online offers rapid iteration, adaptability, and customer collaboration in regard to key and core projects.
Using Microsoft Planner for Agile and Scrum Projects: Microsoft Planner can be utilized with SharePoint Online projects. The application provides features that align with SCRUM artifacts which can then be configured to accommodate Scrum based projects.
Agile Principles in SharePoint Content Publishing: SharePoint Online in Microsoft 365 allows businesses to publish content directly without going through a central publishing team. This offers a much quicker and rapid content management process.
When
using Agile and SharePoint, it’s important to utilize a simple template for a story.
By having a template, it will help the development process of what is actually
needed to be built. As an example, a template is as such:
FOR
<customers>
WHO
<need a piece of functionality>
THE
<product>
IS A
<product category>
THAT
<key benefit>
UNLIKE
<competition, alternative>
OUR PRODUCT <differentiating statement>
Filled in, this could be as such:
FOR
<human resources department>
WHO
<need a web-part to display frequently asked questions>
THE
<frequently asked questions knowledgebase>
IS A
<dropdown of choices of key departments>
THAT
<are listed by category>
UNLIKE
<the information technology web-part frequently asked questions>
OUR PRODUCT <will allow users ti pick the proper category then
allow a response to the requestor via e-mail>
When SharePoint is utilized with agile, the following are
some key tips to utilize during a sprint review agenda:
1)Welcome everyone and state that during this time
slot the SharePoint increments completed will be demoed.
2)State what SharePoint aspects will and will not
be demoed. Usually it is good to have test data in the sites, libraries, lists
and workflows that are part of the demo.
3)Demo the functionality in either a test or
staged production environment.
4)Discuss the new functionality and answer
questions surrounding the delivered increment.
5)Present upcoming backlog items as far as the
features and functionality surrounding SharePoint.
6)Conclude and review what was achieved during the
sprint review and make sure that the product owner will enter and adjust
priorities in the backlog.
Overall – SharePoint and agile scrum are a good fit for many
reasons – the common aspects of Epic -> Feature -> Story and Task are
given an overview below of how they fit together in a SharePoint project.
Epics - SharePoint
agile scrum allows teams to formulate epics (which would encompass a major
release) – overall, epics maybe good for a new installation, upgrade, or
cumulative patch of SharePoint.
Features – in SharePoint
agile scrum, a feature (working functionality usually part of an epic) may consist
of creating a custom web part or creating a new workflow for a change control
process (these can be the features that are part of your new install).
Stories – these are
the aspects that need created/built which will allow users to accomplish what
they need to do in the said system. Stories are usually written in the context
of:
As a <>, I
need<>, so that I get <>. Where the text between the < >
would be filled in by the users or an analyst working with a user.
A SharePoint example of a story would be:
As an end user, I need a button which when checked populates
a list so that I get changes from the change control system from the day
before.
Tasks – as part
of a story – tasks will be needed so that the aspects that make up the stories
asked are created and built.
SharePoint example:
Custom
list is created with proper fields
External content type is created
for change control status field
Form is designed with button lookup
to change control system
Thus – core agile scrum methods can indeed work well for
SharePoint and tweaked and defined based on one’s business needs.
