Complexity, uncertainty and constant change can be managed by adopting a responsive approach to the delivery of software implementation projects. Agile techniques and methodologies have become popular due to the increased need to manage projects in a more flexible manner, without the rigidity imposed by the traditional or waterfall software development methodology. Scrum is one of the most widely used frameworks aligned to Agile and it is adopted extensively across software development teams.
This article highlights some characteristics of scrum teams you should be aware of if you are a business analyst and you find yourself working as part of a scrum team.
1. Product Backlog
Scrum teams refer to the backlog to identify what to work on. The backlog is a list of prioritised work items to be completed by the scrum team, which typically comes from company strategy and ideas relating to the work to be done. Though the product backlog is owned by the product owner, any of the scrum team members may suggest items to add to it. The backlog tends to be in a state of flux as items often need to be prioritised throughout the course of the project, with higher value items placed at the top. The sprint backlog comprises the items (epics & stories) the team commits to deliver per sprint and is usually visible on cards, which are placed on the team wall or an electronic platform like Trello or Jira.
2. Core Team Composition
Scrum teams typically comprise the product owner, scrum master and the rest of the team. The scrum team comprises these 3 core roles which often need to rely on other roles. For example, a scrum team may require inputs from Project Managers, Software Architects, Change Management experts, etc., who are not necessarily part of the core scrum team.
The 3 core roles typically present in any scrum team are:
Scrum Master: This role is also known as Iteration Manager and the person in this position helps the team become effective by removing any impediments they may be facing. This role is also responsible for managing the scrum process and typically would not be the same person as the product owner.
Product Owner: The product owner represents the customer and typically has a solid understanding of the requirements. The product owner is responsible for prioritising the backlog of work to be done, and may need to work with subject matter experts to ensure that key stakeholder requirements are captured. Where the product owner is not available, the role may be delegated to the BA. At the end of each sprint, the product owner signs off on what has been implemented based on the acceptance criteria.
The Development Team: These team members self-organise to ensure that the work planned for each sprint is delivered. It’s a cross-functional team of experts who work collaboratively and may be co-located, if possible, for increased team effectiveness.
3. Epics & User Stories
Work is categorised into epics, from which user stories are drawn. User stories provide a concise technique for describing the functionality of the software application that is being developed. Epics are large pieces of work that are big enough to deliver value to customers but are too large to complete in one single sprint and may take several weeks of effort. Epics thus need to be broken down into user stories, which are small enough to be completed in a single sprint. If necessary, user stories may be broken down into tasks and assigned to different team members within the scrum team.
4. Sprint Cadence
Scrum teams are typically characterised by a two-week sprint cadence. In Agile, a cadence is described as the number of days or weeks in a sprint or release.
5. Small Team Size
Scrum teams typically comprise 7-9 people who deliver working software features every 2 weeks.
Scrum teams are characterised by face-to-face collaboration and feedback amongst team members to ensure that any blocking issues are discussed and resolved. Ceremonies such as the daily stand-ups, sprint planning sessions and retrospectives are used to facilitate collaboration and ensure team members are on board with planned tasks.
Scrum teams may be involved in small time-boxed experiments known as spikes, which are completed within a sprint with the objective of researching or exploring ideas. Spikes can add more clarity to a user story and help the team come up with an informed estimate of how long it will take to complete the user story. Spikes in themselves do not deliver value, but serve as the basis of making decisions or garnering information relating to the implementation of a user story.
8. User Story Estimation
Agile teams often make use of story points to estimate the amount of effort required to complete work items on the product backlog.
Have you worked on a scrum team as a BA before? Do share your experience.