Everyone who has worked with Basecamp 2 knows that it is a convenient, reliable and very simple tool for organizing tasks in small teams. Basecamp 2 is so simple that it does not contain such popular functions as Gantt Chart, estimation hours per task as well as does not have integrations with various third party services like github.com and etc. On one hand this method facilitates working with the product, performing really important functions such as creating tasks, commenting and organizing the tasks list, but there is a need to “finish” the Basecamp 2 system to meet the specific requirements of the team. One of such requirements in the CleanTalk company is supporting “sprints” (this term is from the SCRUM methodology) in the task management system, below I will tell you how we added these sprints to Basecamp 2 for managing our tasks.
Organizing Sprints in Basecamp 2
The steps are below:
- We create a separate project, give it a name relevant to the application and the function that your team provides. In my case let it be “Web development”.
- Add a list of tasks. This list of tasks will be our sprint. In the sprint title we indicate its number, its due date and its status (Open or Closed).
- Example of such title: Sprint 1. Due date July 20 2022. Open.
- Open – notifies the team that it is still possible to add tasks to the sprint, Closed – the sprint is closed for new tasks.
- I recommend putting information about the status of the sprint in its title, as in this case when other tasks from other projects are about to be transferred to the sprint, you will see if your sprints are open or not in the titles of the to-do lists.
- In the description of the to-do list we add information about the utilization of available working hours in the team, taking into account the sprint length. Utilization allows scheduling the number of tasks that the team is able to perform based on the available working hours.
- Example: Utilization of sprint 80/113, Tanya 14/32, Dmitrii 14/32, Mike 31/32, Vitalii 14/28.
- Next, we follow the SCRUM methodology – we assemble a team and plan Sprint # 1.
- We estimate the hours among the team that we have to spent per each task from the Backlog.
- We select the estimated hours from the Fibonacci series.
- The estimated hours are put in the title of each task. Example: Update Bootstrap for Dashboard (19/21). Where,
- 19 – actual hours spent.
- 21 – estimated hours agreed by the team.
- At the end of the sprint planning, we update the Utilization, see point 3. If the Utilization is 100%, we set the sprint status as Closed in the to-do list title.
Calculation of Sprint Convergence
When the current sprint is completed and the next one is being planned, it’s time to calculate the convergence of the completed sprint. Convergence will be considered by two parameters – the ratio of scheduled tasks to actually solved tasks and the ratio of estimated hours to actually spent hours. Example for Sprint #1:
- Convergence by hours 124/113 = 110%.
- If the convergence by hours is more than 100% it means that the team spent more hours on the tasks than was initially planned. In such cases it is necessary to understand what prevented the proper scheduling of the estimated time. If the convergence is less than 100% it means that something prevented some of the planned tasks from being completed.
- Convergence by tasks 18/21 = 86%.
- If the convergence by tasks is more than 100% it is an excellent result indicating that the team has planned the sprint qualitatively. If the convergence is less than 100% it means that the team should review what prevented the previously scheduled tasks from being completed. Determine the cause of the losses and take action to eliminate them.
By simple manipulations we managed to organize our work on tasks in Basecamp 2 according to the SCRUM recommendations.