Even though the web will have many resources available to users on how to get started with Scrum, some folks do find they need help sifting through the massive amounts of information to find what they need.  Recently, I answered some questions for a person in just such a situation who was looking to move their small 3-4 person team to a Scrum methodology.  Following is an excerpt from that Q&A interaction.

NOTE: This post has been based on a Stackoverflow answer I have provided:  http://stackoverflow.com/questions/20298258/what-model-will-be-choose-for-software-project/20301609#20301609

The Scenario

AshwinP asked the question: What model will I choose for a Software Project?

I would like to start to follow the Agile/Scrum Methodology for software development in my projects. How can this be done effectively over the other methodologies and what are the benefits toward project development.

The Questions

1. Can we use Scrum for a Small Project (< 200 Hrs) with 3-4 Team Members?

Scrum can be used for any size of project, but there is some overhead in certain aspects that may not be valuable to you for a <200 hour project. For that small a project, I might suggest you look at something leaner, like Kanban.

2. Are there any free tools available to create Scrum project plans etc.?

If you are looking for Kanban/Scrum work boards to manage your backlog of stories, there are several tools available free online:

• Trello: https://trello.com
• AgileZen: http://www.agilezen.com/
• Scrumy: http://scrumy.com/
• Kanbanize: http://kanbanize.com/
• Many others… just Google and you’ll see there’s a huge list.

If you do decide to go the Trello route, I have some resources on using it for agile task tracking and Scrum:

• Free Agile Task Tracking with Trello
• Using Trello for Scrum
• How to set up Trello Board for Scrum

3. How do I define a Sprint and what is the size and duration of each Sprint?

In regards to “size” of sprint, until you’ve done a few sprints, you won’t know how many story points your team can do in a sprint. This is standard. Your team needs to build up history with each other so you can start determining velocity based on historical performance. In regards to length, given you are transitioning to agile now, I would probably recommend a 3-week cadence. 2 weeks is also good, but can be difficult when the team is first learning agile and losing a lot of time to learning the new process.

The best thing to do here is to use the sprint retrospective to evaluate what is working and what is not, and adapt. If there is too much in the sprint, take on less. If the sprint is too short/long, adjust the sprint duration. That being said, if you do fluctuate the sprint duration you will have a harder time evaluating your velocity as you won’t have similar comparables.

In terms of ‘defining’ the sprint, I assume you mean doing the sprint planning. I would really recommend you take a look at some of the resources on the web for sprint planning sessions. There are websites like ScrumMethodology that have a variety of tools, but if you just Google “Sprint Planning Meeting” you’ll find numerous resources to read.

In general, make sure your backlog is prepped and prioritized, and then you can start working with the team to figure out what you will tackle next and what tasks you will need to do to finish the stories.

4. What is the Product Backlog?

I’ll defer to the Wiki entry on Scrum for you to find the definition. In short, think of it as the list of all the work you have to do that you know about. You will need somebody in charge of this backlog (the Product Owner) who will make sure all the things that need to be done have been created.

If you are working in a larger-scale product company, the product backlog that your development team sees may just be the current release backlog, while there is a longer-term product backlog managed by the product management team that spans multiple releases.

5. Is Sprint Planning part of above?

Again, I’ll defer to the Wiki entry on Scrum for you to find the definition. Sprint planning is an event that allows you to bring your team together and figure out what they are going to do for the next sprint. It is not part of the Product Backlog. It allows you to evaluate what is in the backlog, and then determine what you will take from the backlog and put into your Sprint backlog.

There are a few important questions that get asked in this sprint planning meeting:

• How big are the items in the backlog? (estimation)
• How much of the backlog are we willing to tackle next? (determine sprint backlog)
• How are we going to complete these stories? (task planning)

6. What should be discussed in the Daily Scrum Meeting? How much time will it take to meet?

In your Daily Scrum, make sure folks are just giving updates on what they just did, and what they are about to do. Keep discussions short, and if something comes up that needs further discussion, schedule it for those that need to be involved. It’s just a touch-point so that everybody on the team knows what everybody else is doing, and gives the team a chance to raise issues (impediments). As you go, you will probably adjust how you run your scrum to fit your team, but keep it short (around 15 to 20 minutes).

Using a Scrum Master

Also, I strongly advise having a Scrum master running most of your Scrum events. These individuals are supposed to be experienced (or at least more experienced) than the rest of the team in the agile process and can coach and guide the team to being efficient. If you don’t have somebody on your team already that could answer the questions above, I would strongly recommend you look into finding somebody like that to join your team and help you through the transition.

It is very easy to fail at transitioning to a new process when you don’t have somebody to lead the way!