The course is part of this learning path
This Course provides an overview of the popular Scrum framework, as well as helping you understand what a product backlog item should look like, and why incremental delivery is such a powerful tool.
Learning Objectives
The objectives of this Course are to provide you with an understanding of:
- What Scrum is
- The roles and responsibilities of the different Scrum roles
- What the different Scrum artifacts are
- What a product backlog item should look like
- How to deliver incrementally
- What the Scrum events are
Intended Audience
This Course is suitable for anyone with no prior knowledge of Agile who is considering, evaluating or involved in a move towards working in (or with) an Agile environment.
Prerequisites
There are no prerequisites for this Course, however, participants should be familiar with the content and rationale in the Agile Manifesto (http://agilemanifesto.org/).
Feedback
We welcome all feedback and suggestions - please contact us at support@cloudacademy.com if you are unsure about where to start or if would like help getting started.
The scrum framework helps us to deliver work in an agile way, and it does this by giving us five events to organise our lives and create a cycle that allows us to work at a consistent rate. The five events are, sprint planning, the daily scrum, the sprint review, the sprint retrospective, and of course, the sprint itself. The scrum events are all facilitated by the scrum master, and this is one of their major responsibilities. In this video, we'll go in depth into each of them to help you take what you've learned here and move into a scrum environment.
So first up, we've got sprint planning. The sprint planning happens at the start of every sprint, and it should probably be about between four and eight hours. Four hours for about a two week's sprint, and a maximum of eight hours for a month long sprint, and of course, sprints really shouldn't be for any longer than that. During the sprint planning, the product owner will present the product backlog to the development team and the development team will pull product backlog items from the backlog that they think they can achieve in that sprint. Once they have done this, they'll estimate the effort they need to put into each item, and this effort is represented by things like story points or T-shirt sizes. I won't go into any detail on these right now, but they'll essentially figure out how much effort they'll spend on each item and once they've got all those items in, they've created their sprint backlog. Once each requirement has been pulled into that sprint backlog, there will also often be a task for individual members within the development team to divide or break up requirements into specific tasks that need to be achieved.
The scrum team as a whole will then set a sprint goal. This is basically the objective of the sprint. And that goal is really important to just keep everyone focused on what they're trying to achieve for that sprint. To keep momentum during the sprint, the scrum team use the second scrum event, the daily scrum. This is a very short time-boxed event. Usually only lasting no more than 15 minutes. The daily scrum is used to make sure that everyone in the development team is up to date with each other, and helps everyone understand the status of the sprint. Normally, every member of the development team will answer three simple questions. What did I do yesterday that helped the development team to meet the sprint goal? What will I do today I order to help us achieve the sprint goal? And, do I have any impediments or blockers that are stopping me from achieving what I need to achieve? This conversation allows everyone to quickly understand where the whole team is at. And if anyone needs help, people can jump in, collaborate and support each other. We don't need to use these exact questions. Any will do as long as they allow everyone in the team to be up to date with the sprint progress. It's also very important that the daily scrum isn't thought of as just a progress report. The focus and point of the daily scrum is to synchronise and recommit to the work in line with the sprint goal and to keep the momentum of the sprint.
Towards the end of the sprint, we go into the third scrum event, the sprint review. In it, the development team will present the increment they have been working on to stakeholders and collaborate on what needs to be done going forward. Like the other sprint events, this is a time-boxed event that should last no more than four hours in a month long sprint. So sprint reviews are really important collaborative events to demo what has been achieved and to help keep everyone who's involved working together.
At the end of the sprint, we move into the fourth scrum event, the sprint retrospect. During this, the team has the opportunity to really reflect on their past sprint and talk about what worked well and what didn't work well. It should be time-boxed to no more than three hours in a month long sprint. This allows the team to focus on their ways of working and collaborate to improve going forward. So all of the lessons learned can be captured at that retrospect potentially but is not necessary that this is written down again. Going back to the agile principles, we don't need comprehensive documentation necessarily, but as long as everyone understands those lessons and can take them forward in whatever way, this is probably enough. The scrum team also needs to make a concerted effort to take any lessons learned and discussed in that retro into the next sprint. The retrospective is about continuous process and improvement and we need to take what we've learned into the next sprint planning session.
The final scrum event we need to talk about is the sprint itself. Sprint contain and consist of the sprint planning, daily scrums, the development work, the sprint review, and the sprint retrospective. The sprint is really the beating heart of scrum and all the scrum events take place in it. In it, the development team will create whatever deliverables they're looking to create or whatever services they're trying to deliver or craft whatever they're trying to do. A sprint is a time-box of one month or less. And while it's typically two to four weeks long, it can be as little as one week.
So yes, that's our five sprint events which help us to work in an agile way within scrum. We start with sprint planning where we pull product backlog items into the sprint backlog and estimate the effort needed to complete requirements. We use the daily scrum to keep our momentum going everyday and support each other when we face challenges. At the end of the sprint, we present our work to all our stakeholders and collaborate with them in the sprint review. We then use sprint retro to reflect on the past sprint and to see how we can improve our ways of working going forward. All of this happens in an overall time-boxed event, the sprint itself.
Tony has over 20 years’ experience in Business Development, Business Change, Consulting, and Project/Program Management working with public, private, and third sector organizations.
He has helped organizations to design and create processes and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider, utilizing a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.
As a confident and self-motivated professional with excellent communication skills, Tony is able to bring people together and get them working as a team quickly.
Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Program and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers, and worked at the director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.