Scrum is an agile framework that is often used within software development. Ken Schwaber and Jeff Sutherland developed it together and sell it as a “framework for developing and sustaining complex products.” They summarized principles, roles, artefacts and events in a handy guide called the Scrum Guide.
There are the roles, Product Owner, Development Team and Scrum Master which all belong to the Scrum team. The Product Owner is responsible for a ranked list of stories and features which are required to fulfil stakeholders needs. This list is called the Product Backlog.
In a frequent meeting, the Sprint Planning Meeting, the Scrum Team selects as much as they think they can deliver from the top of the Product Backlog and breaks it down into tasks. This list is then called the Sprint Backlog.
The team will now work for a fixed time (time boxed Sprint) of 2-4 weeks on this tasks and meets every day for a Daily Scrum to plan the next steps. Their desire is to achieve a goal, set during the Sprint Planning Meeting. They may track their progress on a board and probably have a burndown chart showing if all tasks can be done by the end of the Sprint.
The Scrum Master is responsible that Scrum is understood and he is a servant-leader for the Scrum team. He or she facilitates Scrum events, coaches the team, helps to build a high-value product and removes impediments.
After a Sprint is over, the team shows an increment to interested stakeholders and welcome feedback which can flow into a next sprint. The team meets afterwards to reflect on the Sprint and tries to identify possible aspects of improvement.
So were does a Business Analyst fits into the picture? She or he can be part of the team. With her speciality, analysing things, she can be very good in breaking down Product Backlog Items (PBI) in feasible tasks or supporting the Product Owner in gathering new PBIs. She also will be helpful in formulating test cases or facilitating workshops to build up knowledge.
Some good things about Scrum
Visualises status – most teams visualize their progress on a board. This should be for the team only but it could be helpful for external stakeholders to show that work is blocked because of their lack of time or lack of information. Normally, external stakeholders should be informed at a Sprint review level and may see a so called Product Burnup (more later in this blog).
Every sprint leads to a deliverable (e.g. walking skeleton) – That is the desire of the team to deliver something of value very Sprint.
Team gets quick feedback – At every Sprint Review, stakeholders can give feedback on the work done.
Team improves process – This is on of the strongest points and I experienced it so many times that during the Retrospective a team decided to” take their faith into their own hand”s and make sure that test data is ready when they need it or stories are properly tested before they show them to the Product Owner for acceptance.
Product Owner can decide what comes next – The Product Owner needs to be empowered to decide what comes next. That also makes the process extremely flexible. If the marked requires a new feature, the Product Owner can rank it accordingly.
Team is highly focused (shielded, minimal task switching) – The Scrum Master deals mainly with any distractions from outside (she will show Senior Managers the project burnup to let them know the state of the project or he makes sure that a proper integration server will be installed by the service centre).