Best practices when using Sharepoint as a Scrum communication tool [closed]

Question

Right now, our teams are using a combination of a bulletin board and an excel spreadsheet to keep track of tasks and to draw a burndown chart. Backlogs are keep on index cards in envelopes.

This works well when the stakeholders are in the same location. However, we will soon have Scrum teams in two geographically distant locations and I am looking for best practices on how we can leverage Sharepoint to help us communicate around Scrum artifacts (backlog, burndown chart, velocity, etc.).

How did you leverage Sharepoint for that purpose, what are the best practices and the potential pitfalls?

Answer 1

We actually use Sharepoint for our Agile development and have found it works pretty well for project management/collaboration.
There are 2 things we do which I found particularly useful, metrics tracking and automated testing. We use the document library and infopath to add all of our stories for the project to the site. The infopath form should contain all the information you need for a story: points, estimated time, developer, tester, story tasks, test cases.

For metrics, we create web parts for: burn down charts, velocity, points per iteration, etc. This is especially nice for Managers or customers to see that progress being made on the project and will help them make decisions regarding features vs. release time.

For testing we have a simple SEND-RECV-ASSERT language which runs the tests nightly by scraping the XML for automated tests. The we have a little Green/Red webpart on the main page which tells you the stat of the tests.
This can be done pretty simply with some XML parsing since the backend of the document library is XML. (We currently use some simple ActiveX and javascript)

The metrics are pretty easy to set up (just some xml parsing and html charting). The automated testing takes some time to set up a test runner, but once its in place, and easy enough, you can even have customers/managers write acceptance tests! Agile! :)

Answer 2

If you have SharePoint in house already,along with a user base that is comfortable using it I think it would be fairly easy to get started with using it for SCRUM. I would start with the following:

A site collection to hold 1 scrum site per project

A scrum site should contain:

• Document library for the electronic files (add columns for categorization as appropriate)

• List of team members

• Discussion board

The site can be built from a Wiki site template if its necessary.

Once you get the scrum site "feeling right" save it as a template so its easy to spin up a new one.

This solution may not be designed for SCRUM to the nth degree, but it should be enough to get you started. It seems a lot easier than having the entire team learn a new tool when it sounds like you are undergoing some other pretty radical changes.

my $0.02

jt