Scrum for SharePoint: Sprint 0

Before I get into the rest of the Scrum for SharePoint Article Backlog, I wanted to take a moment to talk about what happens at the beginning. It is always important to start things out right, and a Scrum-based SharePoint project is no different.

This is an example of being Agile, right? I am reordering the Article Backlog based on new priority from the Blog Owner (me) and working on the top priority item first, just like we would do in Scrum.

As with everything, how a projects starts will vary based on the project and your particular environment. "It depends." I want to document some ways of handling Scrum for SharePoint and see what sticks. In fact, I am looking for your experiences, good and bad, for different ways for starting up a Scrum project that is building out a SharePoint site, application, or an entire farm.

Many questions come up at the beginning of an Agile Scrum project. In particular: When are we going to have time to set everything up? Good question. If you start your first Sprint developing against the Product Backlog but don't have a development/test and/or production infrastructure in place yet, what do you do?

Scrum is designed to be iterative, which means you have a Product Backlog of functionality that needs to be built, which may change over time, but there is no set project plan. Each Sprint takes a piece of that Product Backlog and builds it out within a certain time box. I'll explain more in future posts. For now, just know that a Sprint is between 2-4 weeks and is focused on developing a certain set of features. The list of items in the backlog changes as priorities change, but once a Sprint starts the priorities for that Sprint are set.

It is possible to build time in to each Sprint to handle infrastructure changes and additions. Even for environments that already exist, you are going to need time to adjust them to fit the needs of the project and Product Backlog. In fact, much of the infrastructure work may be totally outside the Scrum process. Infrastructure, in my opinion, makes a lot more sense as a waterfall project. That said, the development team may still need to be part of the process and it might be too much to ask them to do a lot of infrastructure and development environment work alongside actual development. Which is why I think it's good to start out with something in place before any development begins at all.

If no infrastructure exists—say you are building a brand new SharePoint farm or planning to migrate content from an older version of SharePoint—then more work needs to be done so the development team can hit the ground running at Sprint 1. Do not assume that the team will have time to set things up once they are working on user stories and committing to a certain amount of velocity for each sprint. While velocity can be adjusted to fit in time for administrative or overhead tasks, or user stories can be created to work on infrastructure things (is this even a good idea?), the team's focus will be on building out functionality and it will required a concerted effort to work on anything outside of development.

For environments that already have a full or partial SharePoint infrastructure, the job is much easier but there is still work to do. You need developer environments, a development/build server, a test infrastructure, and stuff like source control and something to manage the Agile process (SharePoint, maybe?). Things will go much smoother if they already exist or there is time to set these up before tackling the product backlog.

I guess my point is that while Scrum for SharePoint can be Agile, you still need to consider the foundation of the project team's resources before any development work begins.

In addition to infrastructure and development resources, the beginning of a Scrum project may also include an assessment of the initial Product Backlog, some agreement on initial team process, and maybe a cursory attempt at an overall architecture. Yes I said there might be some design before you start. Does that go against Agile? More on these topics in future posts.

So, what do you do before starting your Scrum for SharePoint projects?

Back to [Scrum for SharePoint: Article Backlog]
Next in series [Coming soon]

Resources:

• Glossary of Scrum Terms

Scrum for SharePoint: Article Backlog

A few weeks ago I documented my initial thoughts about Scrum for SharePoint. Much like the scrum process, I am going to create a backlog of article topics ("user stories") and then work through them in priority order. Here is the initial set of article topics. This backlog will be updated with links and changes as the article series progresses.

Comments and suggestions are welcome! I am interested in your questions and feedback from your own experiences with Scrum for SharePoint, as well as comparisons to doing waterfall project management.

Topics in priority order (subject to change): [updated 8-April 2012]

Topic Priority 0: Sprint 0

• What happens at the beginning, before the development Sprints start?

Topic Priority 1: Product Backlog

• User stories for SharePoint configuration and customization
• Breaking up SharePoint functionality into one or more user stories
• But this is not all custom code? What do we do?
• Spanning build-out of functionality over multiple sprints
• Technical Debt: Focus on what must be done now but also track what should be done later and making sure it gets done
  • Ideally there is no Technical Debt, but in reality it is hard to avoid

Topic Priority 2: Sprints

• What is a sprint?
• How long should a sprint be for a SharePoint project?
• What happens within a sprint?
• How do you effectively incorporate requirements, design, development, and testing within the sprint?
• When do you consider a feature done?

Topic Priority 3: Team & Process

• Who is the Scrum Master?
• Integration between the development, requirements & testing teams and the stakeholders & product owner
• Development process, deployments for SharePoint configuration vs. customization, continuous integration, and testing (aka Application Lifecycle Management)
• When do you deploy to production?

Topic Priority 4: Overall Design

• When does overall SharePoint architecture and design fit into the picture?
• How to address the overarching technical and graphic design
• What about infrastructure?

Topic Priority 5: Wrap up

• Where do we go from here?

Next [Scrum for SharePoint: Sprint 0]

Agile Scrum for SharePoint Projects

I have worked with SharePoint for seven years now, all the way back to 2005 when I started with SharePoint 2003 after moving off of Microsoft Content Management Server. For much of this time the projects I worked on were run either as waterfall or in an operations & maintenance (O&M)/time & materials (T&M) fashion.

Fast forward to 2011. I moved to a new job at Hewlett-Packard Enterprise Services over the summer and in the fall began my first SharePoint project that fully used the Agile Scrum methodology. Most of our project team was new to Scrum as well, so we all dove into it together for the first time.

Agile is a framework that has a few different official methodologies you can choose from. The basic tenant is to focus on making working products in an iterative fashion and adjusting to change without being stifled by rigid process. This is emphasized by the Agile Manifesto. That does not mean we forget about process, planning, and documentation. We still do those things. It is about balance.

Scrum is one of the most popular agile methodologies, if not the most popular, especially for software development. We use the concept of a “time box” to focus on shorter periods of work while keeping an eye on the overall goal. The Scrum Alliance has a nice, quick intro to Scrum that summarizes it quite well: The Scrum Framework in 30 Seconds.

We are now on sprint 5 of our SharePoint custom development project using Scrum and I am totally into it. The methods are working to give us focus, keep us on track with the most important priorities, and provide transparency to everyone involved in the process including the stakeholders and product owner (customer). This makes a lot of sense, and is how I always tried to work on a smaller scale on previous projects. This just formalizes the flexible yet defined process for everyone involved. That statement probably makes more sense if you have already done an Agile project. If not, read the links below and you too may get indoctrinated.

So what does this have to do with SharePoint, besides the fact that I’m working on a SharePoint project? I plan to break down different areas of Scrum for SharePoint over a few blog posts, which will likely include:

• How the product backlog handles SharePoint configuration and customization
• Integration between the development, requirements & testing teams and the stakeholders & product owner
• When does overall SharePoint architecture fit into the picture?
• What about infrastructure?
• How to address technical and graphic design
• Technical Debt: Focus on what must be done now but also track what should be done later
• Development process, deployments, and continuous integration (aka Application Lifecycle Management)
• More, more, more!

I need to emphasize that there is not just one way to do Agile Scrum for SharePoint, or any project for that matter. I will talk about how we’ve done it and how I have seen other projects do it. The point is, your process depends on your team and your timeline and your goals. It is just a framework and methodology, not a prescriptive guidebook. Consistency is the key. So no matter what you choose to do, you should follow your process consistently. Agile is not a prescription for anarchy. It is a set of suggestions that can be formed together to create your successful process.

Also, I can’t start a discussion about Scrum for SharePoint without a shout out to Andrew Woodward, 21Apps, and their 21Scrum project.

To find out more about Agile and Scrum check out:

• Agile
• Scrum
• Agile Manifesto
• The Scrum Framework in 30 Seconds
• Glossary of Scrum Terms
• 21Scrum – Scrum for SharePoint

The next article in the series Scrum for SharePoint: Article Backlog is up!