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?

Noles

Answer 1

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

Floccule

Answer 2

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! :)

Cumulostratus

Answer 3

You really should consider something like Trello, VersionOne, Rally, or even Basecamp for this. They all have hosted solutions and offer free community versions that you can try out to get started. My experience with SharePoint is that it takes a lot of resources to maintain. If you were using Team System and had a lot of the stuff pre-built for you, that might be different -- although I have Team System and still choose to use a Wiki for my project management tasks. If you already have an investment in SharePoint as an intranet and all of the support staff, then it might be a viable solution in that case, too.

SharePoint is not the tool I would think of first for agile development. YMMV.

Chanty

Answer 4

You need to try and keep the tool from getting in the way of working. In an ideal world the team will all be sat in a single room with big white boards, however often this is not the case and teams are distributed, or theres a push for some form of backup for the post-its.

I'm a big SharePoint fan and where you have this in house already, your already doing collaboration and team work on the platform. Adding another tool, with unique login's can work but the team need to really want to use them.

I've tried getting SharePoint out of the box to do what I wanted but it fell short. I've tried using Version One (on a number of occasions over many years, with many teams) but I find the tool is too much, there are too many otpions and things that need to be done that it gets in the way - it is a long way from the Whiteboard.

So I decided to develop what I needed for my projects. I needed a simple tool, and using the 37signals (creators of basecamp) approach I needed something with less features than the competition.

21Scrum is a simple scrum tool built on SharePoint that uses the platform, add the things that you need (white board, burndown charts) and leave you to get on with the project.

Perhaps this may be the best option for people who already have and use SharePoint - at least thats the goal.

Copley

21Scrum is now live at 21scrum.com – Copley

Answer 5

We've setup a SharePoint workspace with lists for Release/Sprint planning, Product Backlog and Sprint Backlog.

Central element is this Task Board for SharePoint - we can drag & drop stories and tasks - even if we are not at the same location. http://www.youtube.com/watch?v=XW89M0C3N7Q

A burndown report visualises the progress automatically.

Works great!

Minnich

Answer 6

AFAIK, Sharepoint is ASP.net with free goodies. It is not designed for agile project management.. so you'd have to roll your own site.
IMHO instead of trying to bend the job to the tool you have.. switching to a better tool for the job would be a better option. Check this thread out to see if there is something more lightweight that fits your bill.

Also personally I'm a big fan of not digitizing the development activities.. So I'd use a spreadsheet for the backlog and post its and Big Visible charts. Use a digicam to persist diagram/design discussion snapshots (google whiteboard photo for tools) or for reports. I find that most of the "project management" tools are just excuses for generating instant status updates.. it gets in the way of software development (which is the main goal) and inhibits social interaction way too often.

(disclaimer: absolutely 0 experience with sharepoint.. except what I've read in the last 2 days so may be totally off track)

Cita