The principles of agile product development emphasize on the active user and Product Owner/ business involvement. A collaborative and cooperative approach between all stakeholders is also essential. With this in mind, it pays to take a closer look at the collaborative tools used in your development processes.
For Scrum Masters who find themselves working with a relatively new team, it makes sense to select tools that will enhance collaborative efforts within the Scrum Team, as well as other stakeholders in the organisation.
For Scrum Masters working with a more mature Scrum Team (Product Owner, Scrum Master, and Development Team) and successfully delivering product increments for a number of sprints, making a change in one of your collaborating tools can improve agility.
Whether you are a Scrum Master setting up a new team or one that is working with a mature Scrum team, taking a step back and analysing the collaboration tools can take your team performance to the next level.
Select the right collaboration software, for more effective agile performance.
Top left: Slack, Yodiz, JIRA, Zoom.
Here’s a guide to what feature each of these tools would need to have so that it can effectively serve the team.
1) Organisation communication tool
What is the primary method for communication within the organisation? Is it a real-time messaging tool with file sharing capabilities, or e-mail?
Scrum teams should be meeting daily and have face time with the Product Owner. However, after the 15-minutes Daily Scrum, having a business communication tool in place that supports team collaboration provides the ability for constant communication. These quick responses and turn-around time help improve productivity and agility within the team.
For organisations using the combination of a chat and e-mail for this purpose, the change to an instant messaging tool for business will allow for these added benefits:
- Creating small group chat (channels) for improved communication within smaller teams
- Allows for teams to self-organise, improves collaboration
- Attaching images, screenshots and other relevant files to the conversation for a more agile development process
- Integration with the Product Backlog, Sprint Backlog or the video conferencing tool used for distributed team communications
2) Product Backlog
The Product Backlog is owned and maintained by the Product Owner or Product team. It is a tool used to gather, discuss and expand on product requirements. In an agile development environment, requirements usually evolve as new data is gathered by the Product Owner. Discussion between stakeholders and the Tech lead takes place. It is beneficial that these discussion threads are recorded to avoid having the Product Owner repeat the conversations that took place earlier. Epics are broken down into user stories and then into more granular tasks, as they emerge closer to engineering sprints.
The Product Owner should be able to constantly re-prioritise these granular tasks in the Product Backlog. A simple project management software that enables the Product Backlog Items (PBI) to be dragged up and down the priority list is more efficient than a static list.
The Product Backlog software would need to enable the Product Owner to effectively carry out these activities:
- Easily re-prioritise the Product Backlog Items (PBI)
- Keep a record of the discussion threads between the Product Owner, Tech lead and other stakeholders for each PBI
- Estimate each PBI (this is useful to have during the Backlog Refinement meeting)
- Ensure PBI are visible and accessible to the development team as well as other stakeholders in the organisation, at any point in time
A simple Project Management tool would be more effective than a Product Backlog that is groomed on a notepad or a spreadsheet.
3. Sprint Backlog
The Sprint Backlog is the development team’s interpretation of the Product Owner’s tasks. It usually mirrors the Product Backlog. However, each Product Backlog Item (PBI) could be represented by more than one task in the Sprint Backlog.
Development team members usually add other tech-related tasks to this backlog.
The benefits of using a software development tool and not a physical board (with post-its) to represent the Sprint Backlog are:
- Development team members are able to access the Sprint Backlog at any given time and location, during the sprint. A sprint backlog represented in a digital format allows for distributed team members. It also allows team members to work remotely.
- Ease of use and promotes usage. Team members are expected to update the sprint backlog as new information is available. This usually happens daily. The selected software development tool should be easy to use yet powerful enough to provide adequate customisation for your team’s preferences.
- Digital sprint backlogs allow for advanced team data capture and analysis. Most tools come with built-in report generation features. Standard sprint reports such as Burndown chart, Velocity chart, and sprint report are easily generated. For teams using Kanban, Cumulative Flow Diagram (CFD) and Control Chart can be generated. Analysis of these reports can be effectively used at team retrospectives.
- The definition of done is understood by the team and is illustrated in the columns in the Sprint Backlog (board).
4. Daily Standup
If you have distributed team members, or allow Development Team members to work remotely, then a good video conferencing tool is essential to ensure team members are able to communicate well.
The video conferencing software can be used for Daily Standup, for distributed teams.