Scrum is comprised of Sprints, which are fixed periods of time, each of which are typically between one and four weeks. The point to this is accomplish tasks in incremental pieces. Because each sprint is so short, it allows projects to cope with uncertainty and changing requirements.
The 'ceremonies' are only a part of the scrum process. Different to other agile practices, Scrum can be divided into:
You can find lots of information on this online but here it is in an easy to refer, one pager.
The Scrum Master helps the Team and Product Owner in their efforts to make the organisation successful. The Scrum Master serves the Team and removes impediments, protects the Team from other parties, and promotes Agile practices. The Scrum Master does not manage anyone and does not seek to represent or lead the team; merely to facilitate and help the team
The Product Owner is responsible for the product which is being worked on. They identify features, putting these in a backlog and continually refines and prioritises it to form a sprint backlog. The Product Owner should set the Sprint Goal for every sprint in order to create the shared goal for the team to focus on. Ideally there should be just one goal but real life scrum teams may find several Sprint Goals hoisted upon them.
The 'Devs' is a term for the other members of the Scrum Team. They can be developers, designers, analysts, domain experts or anyone else who must develop the product. The devs should become self-organising and committed to the product increments
This continuously improved list will change to identify what is necessary to make the product. It contains everything, not just user stories, but defects to be fixed, and changes - anything that needs to be done in order to enhance the product. The items that make up the Product Backlog, the Product Backlog Items (PBIs) are sorted by criteria such as value, the necessity, and priority. All of this may be combined into one rating, and referred to as the priority.
They may also be weighed against cost of implementation or the complexity. As always with Agile, the team knows best.
We want to reduce waste, right? That's why Product Backlog Refinement is only 5-10% of the sprint. It can be done either in a meeting, or on an ad-hoc basis. The goals are to make the items:
- Clear enough and understandable by everyone in the team. Details we add will include information such as the Acceptance Criteria.
- Small enough to be put in a sprint.
Therefore items in the Product Backlog that tend toward a higher ranking priority should be clearer and better defined than those of lower rank. In other words, we aren't wasting time trying to understand everything at the beginning. By this point, all of our items will have been broken down so that they can be achieved in the sprint time box. These items are considered to be 'ready' and can be candidates for the next sprint.
Should Test Cases be created during refinement? Scrum has no specific stance on this, so the team can decide. However, Scrum does say that items should be Done by the end of a sprint and therefore should meet the Definition of Done. Does the team want to include testing in this?
One of my teams created test cases and during a sprint a user story was only DONE when:
- All test cases were executed
- Defects were fixed and failed test cases were retested
- User story was reviewed again against the acceptance criteria and product behaviour was sense checked
This consists of the Product Backlog Items selected for the next sprint in order to meet the Sprint Goals. The Sprint Backlog is the development team’s expectation of which functions will be included in the next increment. In order to complete the selected items, tasks will be added in the sprint.
This is simply the next iteration of the product. The completion of every sprint will result in new, incremental value being added to the product.
This is the first thing to happen in the Sprint. The Scrum Team will also craft a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of part of the Product Backlog, and it provides guides the Development Team on why it is building the Increment. All work done by the team should tie directly to this. If new work is given, then unless it ties directly to the goal, it should be deferred and not done during the sprint.
Part 1) Deals with the 'what'. The Product Owner and Development Team will discuss the ordered (highest priority) Product Backlog and the Product Owner will describe what the Sprint should achieve and the Product Backlog Items that, if completed in the Sprint, will be done. The entire Scrum Team will collaborate on understanding the work of the Sprint and it is vital that the coders are also there.
Acceptance criteria will be checked, and the Development Team, knowing their own capacity and past performance, will decide what they can work on and commit to doing this by the end of the spring.
This will take 1 hour per week of sprint, so a two week sprint will need 2 hours for part 1 planning.
Part 2) Deals with the 'How'. The Development Team can break down the stories (or other such item that needs to be built) into tasks as it will enable the team to consider all possible actions that are needed to finish the stories, including the testing effort.
The tasks can be thought of as the requirements which realise the user story.
The Product Owner is an optional attendee at this stage as he/she may wield undue influence over the solution. The Product Owner should however always be available.
This will take 1 hour per week of sprint, so a two week sprint will need 2 hours for part 2 planning.
The Daily Scrum is for the Development Team. Though others are welcome, they must not be allowed to disrupt the meeting. What the team wants to understand is, 'are we on track?' and does this by inspection and adapting.
When the Sprint begins the Development Team will have a Daily Scrum, sometimes referred to as a Stand Up in order for it to be quick (Scrum Master may arrange and may facilitate as required). It should be 15 minutes and if we go by the book, it is done in order for team members to talk about what they have done, what they are going to do, and whether there are any impediments to progress.
This approach can be robotic and it will be a struggle to keep everyone engaged. A variation of this is for team members to talk about how they have helped the team progress to meet the Sprint Goal and what their issues are.
It's very easy for the team to turn the Stand Up into a status update or problem solving platform, extending to 30 mins plus. The facilitator will need to know when to shut down the conversation and arrange for a separate forum to discuss certain topics in order to keep to the discipline of the Stand Up.
In fact it should be encouraged that team members collaborate after the ceremony to solve their problems.
The attendees will be the Scrum Team and key stakeholders invited by the Product Owner.
At the end of each sprint there should be a product Increment that can be demonstrated. The Product Owner will explain which of the Product Backlog Items have been 'Done' / not "Done", with the goal being to get feedback to ensure that the work done, or the Increment, satisfies the business need.
However, it's not just validating what has been built, it's also a chance to feed in how the market may have changed, or potential use of the product.
The feedback can be added back into the Product Backlog, where it can be pulled in to a future sprint by the team.
This will take 1 hour per week of sprint, so a two week sprint will need at most 2 hours for a Sprint Review.
Also at the end of the Sprint, the team will reflect on the previous sprint in order to incorporate continuous improvement improved speed. It's where the team self inspects and adapts. What it is not is a forum for blaming others. It should be a safe place that encourages the truth to emerge.
There are different ways of doing this, but the underlying purpose is to understand what went well, what did not go well, and what can be improved upon for next time. Improvement can happen at any time, but the ceremony provides a formal opportunity for this to happen.