To explain the third opportunity, I will need to set the stage. I use Scrum on In-The-Ditch (ITD) projects. At the start of every new job, there is at least one ITD project. If I am lucky(kidding), there might be two. To earn my ITD classification, a project has to have three main characteristics:
- The project is always over budget. Until the project is over budget, the project team and sometimes the project manager, are convinced the schedule can be caught up.
- If a scope is defined for the project, it will not reflect the functionality that has been built yet, nor will it represent what is going to be built.
- The project plan does not reflect the activities required to complete the project.
While not all the characteristics may be visible, they are all related to each other and are buried just below the surface. Once one of the characteristics is identified, the Scrum process should begin. The process is as follows:
- If there is a project plan, copy any items that are not marked as complete onto the Product Backlog. Include testing related activities such as developing scripts, automating regression, etc.. However, the actual test execution should be left off.
- Review the Product Backlog in workshops with the project sponsors, SMEs, and the development team. Any items not included should be added to the backlog. A baseball ranking (A scale starting with one in order of priority, with no duplicate rankings) should be used to prioritize the items on the product backlog.
- The “Product Owner” should review the highest ranked items to ensure they are at a level of detail that will allow them to be included in a sprint. Lower priority items can be at a higher level of detail.
- Planning Poker should be used to estimate each of the items on the Product Backlog.
- The estimates should be accumulated, multiplied by factor ( I use from 2.5 to 2.5, depending on my feel for the development team and the environment). I get a lot of pushback if I have to disclose my factor, but the reality is the people pushing back generally have where the main contributors to the project being late. I have to address the issue, and it is usually painful, but I stick to my number.
- Initiate development using the Scrum framework with the steps identified in post #1.
- A project plan (schedule) should be developed containing the number of sprints and releases required to complete the project. Since the ITD started as a Waterfall project, the project sponsors will be looking for something familiar that will make them feel comfortable the project is back on track. The tasks estimated in step #5 should be added together. I use the following calculation to figure out the number of sprints I need: # of sprints = total hours from #5 / (resources * 80). Sprint tasks are then added with The last two sprints are for user acceptance testing
- Divide the number of hours by the number of resources that are included in the development team. This gives you
- Add the PM time as one task over the life of the project. This keeps the PM out of the actual sprint numbers.
- Sprints need to be included, so take the number of hours from
Implementing Scrum at this point accomplishes a number of small victories. Daily Standups will identify impediments, provide insight to progress, and facilitate communication amongst the development team. (Am I the only one who is amazed that developers sitting in cubicles right next to each other will not talk till they get in the Standup?) In addition, doubling the estimates creates some margin for error. In my last ITD, I realized that the Planning Poker is required. More eyes on the estimates and the project plan produce better results.
I have used these techniques a number of times over the years. These steps work very well. Hopefully you won’t have to use them, but the odds are you will create or inherit an ITD. When you do, you will know where to start.
Thanks for coming in today.