We use sprint planning for both internal and external projects, it forms part of our agile approach to projects. By using smaller tasks to achieve an end goal it makes it easy for the team to contribute based on their strengths and see where we might need to focus more of our efforts to reach the that goal.
The prioritisation of tasks is done using a value vs complexity chart, where we add these tasks to work out which should be done first and which might be ‘nice to haves’. We also practice this with clients. Working with them to prioritise their users needs. Often seeing the goal set out visually can make clients rethink their priorities and realise what is achievable in their budget.
Sprint planning helps us reach our goals!
The minimum our sprints will last is one week and the maximum is up to 4 weeks. In between each sprint we like to have downtime where the team can blog, reflect and review. When scheduling time for sprints there are factors we need to consider such as client budget, goals and project length. It can often be that we will schedule a sprint for an ongoing project which will last 4 weeks then allow a break for the client to review and amend. We don’t use any fancy software in the initial sprint planning just old fashioned sticky notes, markers and a whiteboard.
Our sprints usually take place on a Friday, this allows us to review the current week’s sprint and plan for the next. Some goals may take more or less time to achieve than estimated or goals may have moved or changed. By holding sprint sessions on a Friday come Monday everyone knows what goals we need to achieve that week.
Our sprint sessions start with the overall goal, then issues are broken down into individual tasks to be completed to hit that goal. These issues are then added to the GitLab and Trello backlog. Within these tools we are able to add labels which correspond to it’s value vs complexity i.e. is it high value/short time or low value/long time. Using Git and Trello we can assign team members, view boards and create sprint milestones which allow us to create burndown charts along with giving access to clients so they can see the progress being made.
Even if we plan for a sprint to run for 4 weeks at the end of each week we sit together, re-evaluate and re-assess in order for the team to continue moving towards the project goal.
Gitlab burn-down chart