Geeks With Blogs
Jennifer Zouak JENNIFER · ZOUAK's · BizTalk · and · .NET · column

Working wtih sharepoint (wss) and scrum... it is neat how the backlogs (lists) can build out quickly. But Sharepoint doesn't by any means enforce a process. The maximum access but the minimum governance.  Some tips:

1. Learn scrum first, then implement on Sharepoint. Doing it backwards will have you duplicating the "waterfall" microsoft project tasks in to Sharepoint.

2. Figure out how you will do your "burndown" based on a sharepoint list. Either you manually grab the data daily, or you write something to automate it. I haven't done this yet, but options are 1) Using a (3rd party) worfklow copy the hours for each task into a 2nd list to capture the burn rate. 2) Write external code which executes on a schedule and grabs the data, saving it somewhere safe.

3. Synchronize your time tracking tasks to the Sprint tasks. Even if 1 to many.

Futhermore, SCRUM is really organized around product development. You know, the traditional options of adjusting features, schedule or cost? I work in services and sometimes I think we must be the only ones who have adopted SCRUM for this... there is no advice on the googlesphere for how to run Professional Services on an agile basis. Perhaps because we aren't supposed to be agile: Once a client signs, they pretty much expect that they are going to get all the bullets in their contract, be billed no more than the estimate and delivered by the due date. Everything is in writing at the begining. In some domains (marketing) services is more agile, sure, but *integration*? Not. Data still has to make it from point A to point B. Here are my thoughts on how we are going to make SCRUM work for services, comments welcome:

A) The start-of-SPRINT meeting will actually be help as each new project/SOW/Change Order is scheduled by the project manager. The line items from the project plan/SOW/Change order, are entered into the Product Backlog. 

B) These same items are entered into Time Tracking system as high-level tasks for billing purpose. In time tracking, there needs to be a task to handle cooperative coding which sometimes happens in functional teams. This is simply collaboration, not the 'extreme' model. (In services, all time is billable-- we don't want to inflate the wrong task). ps. Project managers hate generic buckets -- fun :) trying to get this one through.

C) Next, the team meets and translated the bizspeak into actual development Sprint Backlog tasks (no more than 16 hours per item). The backlog tasks have (FK) relationship to the Product Backlog. If the relationship isn't there, then it would immediately indicate a missed requirement.

D) Finally, if doing actual Sprints, the new spring backlog items need to be assigned to Sprints. Other items may be demoted from current sprint to make room. Recommendation is to have many future Sprints in the system to allow forward booking. Assign resources to any tasks for current sprint and also where it makes sense -- you can always re-assign.

E) Burndown chart needs to track hours on a per-project basis. The burndown chart will only make sense if the tasks are being actively worked on. If things are on-hold, or a developer is temporarily re-assigned.... the graph will flat line. This will be an indication of resource issues rather than increases in amount of estimated work. I wonder if there's a way to compare the reported dev hours (from time tracking) to the burndown? -- the delta would be more informative.

F) Daily stand-up meeting would have to go project-by-project. Managment needs to schedule its own meeting outside this.

 

Posted on Monday, September 22, 2008 1:04 PM Sharepoint , Professional Services , SCRUM | Back to top


Comments on this post: Sharepoint & Scrum

# re: Sharepoint & Scrum
Requesting Gravatar...
Hi Jennifer,

I am leading several scrum projects and we use sharepoint organizationally for other purposes. We would like to find a way to utilize Sharepoint for agile project management including backlogs, user stories, tasks, estimates, burndowns, etc. Do you know of any resources that are available for accomplishing this in Sharepoint?

Thanks!
Roland
Left by Roland on Jan 09, 2009 3:43 AM

# re: Sharepoint & Scrum
Requesting Gravatar...
This is an old post, but I thought it worth commenting. I been doing agile development for years and SharePoint more recently. I found the same issues, I wanted and tried to get Scrum to work in SharePoint as this is where all the reset of the team collaboration was centred. Too many times we ended up using totally 3rd party solutions and lost the integration.

With the introduction of SharePoint 2010 I decided that I really would put Scrum into SharePoint and have just launched 21SCRUM (http://www.21scrum.com).

Would love to get your view on how this fits with your experience of doing Scrum, and particularly Scrum in SharePoint.
Left by Andrew Woodward on Jun 21, 2010 4:39 PM

Your comment:
 (will show your gravatar)


Copyright © Jennifer Zouak | Powered by: GeeksWithBlogs.net