History of Scrum
In their 1991 book, The Knowledge Creating Company, the pair argued that Scrum is, “especially good at bringing about innovation continuously, incrementally and spirally”, leading to a form of organisational knowledge creation.
The term Scrum comes from Rugby, whereby the whole process is performed by a single cross-functional team, across multiple phases trying to move the ball forward as a unit. Commercial product development benefits from an increase in speed and flexibility.
Sutherland and Schwaber teamed up in 1995 to present the framework at the Business Object Design and Implementation Workshop in Austin, Texas. Sutherland and Schwaber continued to collaborate and develop the framework based on experience and learned best practice.
Mike Beedle joined Schwaber in 2001, to produce Agile Software Development with Scrum. A key approach of Scrum is to bring the decision-making power to those delivering the product, not being blocked waiting for decisions from senior authority.
The Scrum Alliance was founded in 2002 by Schwaber, this included the Certified Scrum accreditation series. Schwaber later moved on from Scrum Alliance and created scrum.org which runs the Professional Scrum accreditation series
The Scrum Guide was published in 2009 and is widely considered the official definition of Scrum. The Kanban Guide for Scrum Teams (2018), expands on the definition further.
My experience with Scrum and Agile
I’ve been a Certified Scrum Master since 2015 following my course led by Martine Devos. Prior to this I have practised the values and principles of Agile since 2010 as a Developer.
My client list over that period has grown to over 25, resulting in multiple projects of ongoing development with each. Industries including Hospitality and Health have been prevalent but not exclusive, other areas include e-Commerce, Social Networks, Unique Start-ups, and internal projects.
I have delivered hundreds of iterations of products, starting in a hands on development role and naturally transitioning to management and delivery as a result of many successful and productive interactions with both technical and non-technical parties. My greatest strength is in keeping the focus of desired outcomes as the top priority, keen to have the difficult conversations to gain key information that steers the development in the right direction for stakeholders, and increase velocity of delivery by gaining the collective agreement of all involved.
Three core roles exist in the Scrum team; the Product Owner, Development Team, Scrum Master. The team can work remotely, but for the greatest potential for delivering a shippable product ideally the team will be co-located.
Representing the stakeholders and acting as the voice of the customer, the Product Owner is responsible for creating the product roadmap, maintaining the product backlog, and ensuring the outcomes delivered by the team provide the maximum value. The Product Owner communicates the requirements in common language so that all parties from stakeholder down to acceptance testing can understand and agree what is required and when a deliverable is considered complete.
The product backlog is the list of known deliverables in varied states of readiness for development, from a simple idea to a fully specified definition ready to be adopted into a sprint. The Product Owner maintains the priority order of these deliverables so that the Development Team address requirements in the correct order of importance.
Scrum teams consist of a single Product Owner, the one true voice and decision maker focusing on the business value and spending the majority of their time with the various stakeholders. The Product Owner should not be concerned with the technical solution a team reaches, and only ensure they are available to address questions and concerns the Development Team come across during the development of an outcome.
The Product Owner is the core communicator, responsible for conveying the organisational goals, values, required outcomes, and priority. The ability and willingness to effectively communicate with team members and stakeholders is key to ensuring the product development maintains the correct direction.
The ability to convey empathy is important, to put on various hats and appreciate the perspectives of players involved throughout the product definition, development, and delivery make a great Product Owner. Willingness to have difficult conversations and make difficult decisions are crucial in such a fast paced framework, to actively collaborate and declare the best course based on the information available at any given time.
Consisting on between 3 and 9 members, the Development Team conduct all tasks required to build and deliver the product increment including; analysis, design, development, testing, technical writing. The Development Team members are generally referred to as Developers, even though each individual can represent a specific discipline.
Self-organising and cross-functional, the Development Team consisting of software designers, engineers and testers, core responsibility is in delivering a potentially shippable product at the end of each sprint.
The Scrum team is facilitated by the Scrum Master, the team member who is responsible for removing impediments and unblocking tasks.
The Scrum Master is not a leader or manager of the team, but a coach and servant to the team ensuring the principles of Scrum are followed to ensure the optimum team velocity and prevent any distracting influences.
Facilitating ceremonies, the Scrum Master is there to assist and encourage the team to improve working practices to deliver more effectively.
Core responsibilities include (but are not limited to):
- Assisting the product owner in maintaining the product backlog, ensuring the needed work is well communicated and understandable so the team can move forward with developing
- Helping clarify the definition of done for the product
- Coaching Scrum principles to deliver high-quality features
- Promoting self-organisation
- Addressing and removing impediments, whether internal or external of the team
- Facilitating ceremonies to ensure regular progress
- Educating key stakeholders on Scrum principles
- Coaching the development team in self-organisation and cross-functionality
A Sprint is a fixed period of time during which a development team commits to deliver a collection of tasks designed to conclude with a demo of a potentially shippable product. The duration can be between 1 and 4 weeks, and is most commonly set at 2 weeks.
A working product at the end of each Sprint is emphasised in Scrum, meaning the product iteration has been fully integrated, tested and documented.
A Sprint begins with sprint planning, where the development team along with product owner and scrum master meet to discuss and commit to a segment of the product backlog to be promoted to the sprint backlog for development during the current sprint. The sprint ends with a sprint review to show stakeholders the delivered work from the sprint, and sprint retrospective where lessons are identified and improvements to be applied in future sprints.
The first task at the beginning of any sprint is to conduct the sprint planning event, the development team meet and collectively agree on the scope of work that is realistically deliverable in time for the defined end of sprint.
The outcome of Sprint Planning is a sprint backlog for the current sprint, a collection of items taken typically from the top of the product backlog. The meeting is recommended to take 2 hours for every week of the planned sprint – a 2 week sprint should take four hours.
The first half of the Sprint Planning session consists of the whole team selecting the product backlog items that can be completed during that sprint.
The second half of the Sprint Planning session involves identifying the work required to complete each item, ultimately resulting in a sprint backlog commitment.
Some product backlog items may be too large and require breaking down to smaller tasks, while other items may lack sufficient detail and be rejected by the development team until deemed ready for development.
The Daily Scrum is typically conducted first thing every day, should start at the same time and take place in the same location whilst being limited to 15 minutes.
Each team member comes prepared to cover what they achieved yesterday, what they intend to achieve today, and any blockers that may impede progress
The Scrum Master captures any impediment raised during the Daily Scrum and displays this on the Scrum board for all to see, with a designated team member working to resolve.
No detailed discussions should take place during the Daily Scrum. Anyone is welcome to attend the Daily Scrum, but only the development team will contribute to the content of the meeting.
At the end of the sprint the team conducts a sprint review where the competed work is presented to stakeholders in the form of a demo, and work not completed is covered but not demonstrated. The team and stakeholders then collaborate to discuss what to work on next.
The sprint review should be restricted to 1 hour per week of development – 2 hour Sprint Review for a 2 week sprint.
The Sprint Retrospective is a chance for the development team, facilitated by the scrum master, to reflect on how the sprint went, the ultimate goal being to identify processes that can be improved in future sprints.
Two key questions should be asked:
- What went well during the sprint?
- What can be improved in future sprints?
The Sprint Retrospective should be restricted to 45 minutes per week of development – 1.5 hours Sprint Retrospective for a 2 week sprint.
The Product Backlog is a list of the product requirements for intended for future development, listed in priority order usually from top to bottom with the top being highest priority. Items at and near the top should be ready or near ready for the development team to pick up and begin work, safe in the knowledge that the item contains sufficient information to deliver a piece of work during the sprint.
User stories and use cases help all parties to understand where a requirement came from and what is the intention in developing such a solution, with a focus on value derived from the completion of a feature.
The product owner is responsible of and the sole owner of the product backlog, ensuring the information in each requirement ticket is up-to-date and in priority order.
Each product backlog item should include the product owner’s assessment of business value, ideally supported by data often provided by a business analyst. As items graduate to the sprint backlog they are each assigned a value to represent perceived development effort, this assists the development team in; declaring a reasonable sprint commitment, informing the product owner if an item may be too large, and give a clear indication of development velocity.
Product Backlog items typically exist as:
- features (wanted functionality)
- bugs (unwanted or unintended functionality)
- technical work (e.g. performance analysis)
- knowledge acquisition (research)
The Sprint Backlog is the list of items committed to by the development team for the given sprint. The commitment is an estimate and not a promise to deliver the work by the sprint review ceremony, the development team can use past performance in the shape of a velocity metric to more accurately predict what can be delivered. During the first few sprints where past performance is not available, it is expected that the commitment will be a best guess and likely to be wrong.
Sprint Backlog items are never assigned to a particular team member, instead items are addressed in order of priority and taking into account available skills within the team. This process of self-organisation encourages the team to maximise their strengths to promote the highest velocity possible.
The Sprint Backlog belongs to the development team and is usually applied to a sprint board.
The Sprint Board is a physical or digital board consisting of multiple columns to visualise a sprints progress at any given time. The number of columns can vary but a typical board will have To Do, In Progress, Code Review, Testing, Done.
Team members move items from left to right a they are developed until they reach Done, at the end of a sprint the items in Done are considered ready and part of the potentially shippable increment or product increment.
The Product Increment is the collection of Done items at the end of a sprint increment, successfully integrated with the work of all previous sprints. It is up to the product owner whether the Product Increment gets shipped or is put on hold until a future date.
The Product Increment is demonstrated to stakeholders to enable visibility and encourage collaboration and discussion of what to work on in the next sprints. Once the demo has concluded and sprint retrospective has been completed, the development team return to the product backlog to begin the next sprint.