A colleague of mine asked me what it would look like to implement some Agile project planning for a software team that works with a fairly ad-hoc management system now. I thought others could possibly benefit from this information so I am posting it here for all to see. What I am trying to picture is a way for an unstructured team to ease into a more disciplined approach to managing a software project.
Team Planning Meeting
We start the week with a team planning meeting. During this meeting we review all the outstanding tasks and select enough of them to fill one week of development for the entire team. This means that ALL tasks will need to be described adequately and have estimates. Since the customer will select which tasks should be added to the next week’s work, we will always be working on what is most important to the customer.
Daily Work
Each day the developers will take tasks from this week’s task list and complete them. We will track the completion during the week with a Burndown chart that shows how much work is left to complete by the end of the week. The burndown chart will be updated at least once each day in preparation for the daily stand-up meeting.
Emergent Tasks
There are three kinds of emergent tasks that the team should have a contingency plan to handle.
- Emergency Fix (Show-stopper): If an emergency happens that needs to take priority over what is planned for the sprint and it cannot be worked-in (see High Priority) then the sprint must be abandoned while the team addresses the emergency and we will start a new sprint next week. All effort to avoid this case should be taken as it will create work that must be re-done in a later sprint.
- High Priority Task (Needs to be done now): If a task comes in that is higher priority than those in the current sprint and it cannot wait until next week then the customer must remove tasks from the current sprint to make room for this task. If a task that has already begun work is removed it is likely that some or all of that work will need to be re-done at a later time. Again, we should attempt to avoid this case if possible but the impact can be minimized by removing only tasks that the team has not started working on yet.
- New Task: If a new task comes in to the team then it should be detailed by the product owner (product owner or designee) and estimated by the development lead (lead developer or designee). It is the responsibility of the team to ensure that ALL new tasks that come in during the week are detailed and estimated prior to the next team meeting.
End of Sprint
At the end of each sprint the team will have a meeting where the developers/team members demonstrate the new features to everyone that the customer decides should attend the meeting. Additionally, we will review the burndown chart and declare how many tasks were completed. The declaration of completion gives us a simple metric that we can use for planning future sprints. Since all sprints are the same duration it is expected that the team will complete approximately the same number of tasks in each sprint. After some time, the empirical evidence of team performance will lead us to more and more accurate time estimations.
It is common for Agile teams to combine the End of Sprint meeting with the Team Planning Meeting. For example, we could schedule a meeting every Monday morning where we close the old sprint, take a ten minute break, and start the new sprint. This keeps the number of meetings to a minimum.
