In my first article Introduction to Agile Development and Scrum we looked at Scrum from a more of a holistic perspective. In this series of articles which I’ve named "Scrum in Practice" we’ll be looking at Scrum in a much more pragmatic way and look at examples of how to actually do Scrum in a more practical and fundamental way. Since Scrum is not a strict methodology but rather a process framework for development it is typically done a bit differently from organisation to organisation. There are however some basic elements that need to be in place to do Scrum well and some best practices that everybody should know. I’ll try to cover what has worked well for me over the years as well as some potential problem areas and solutions.
Basic requirements for Iterative development using Scrum
Just to quickly recap from the Introduction to Scrum article these are some of the key requirements for iterative development when using Scrum:
- Iterations must have fixed time boxes and be less than 6 weeks long
- Code at the end of the iteration must be tested by QA and be working properly
- A Scrum team must have a product owner and know who that person is
- A Scrum team must have a Product Backlog with estimates created by the team
- The team must have a Burndown Chart and know their velocity
- There must be no one outside a team interfering with the team during a sprint
Scrum’s Roles, Artifacts and Rituals
Scrum consists of several key elements that make it a solid framework for development and project management. These elements can be broken down into three roles, three artifacts and three ceremonies or rituals.
- Scrum’s 3 Roles
- Product Owner
- Scrum Master
- Scrum Team
- Scrum’s 3 Artifacts
- Product Backlog
- Sprint Backlog
- Burndown
- Scrum’s 3 Rituals / Ceremonies
- Sprint Planning
- Daily Scrum (daily stand-up)
- Sprint Review (Demo & retrospective)
Three core roles in Scrum
There are 3 core roles in Scrum, people in these roles should be committed to the project and the Scrum process.
- Product Owner: Represents the stakeholders and the business, prioritises items in the backlog
- Scrum Master: Facilitator and project manager. Acts as an advocate for the process
- Scrum Team: Cross functional team of 5-9 people. Self-organising, does the work and implementation.
In addition there are supplemental roles referred to as "Stakeholders" and "Managers". These people typically have a vested interest in the project or development but aren’t committed to the process and typically aren’t held accountable for any failures or delays. The opinions and input of these people needs to be taken into account but they should not be allowed to directly interfere with the team.
I’ll go into much more detail on the Roles in Scrum in my next article.
Three primary artifacts in Scrum
- Product Backlog
- Sprint Backlog
- Burndown
Product Backlog
The product backlog is at the heart of Scrum. The product backlog is essentially a prioritised list of requirements, features, improvements, fixes and so on. Items in the backlog are things that the customer(s) or users want, or things that in some way enhance the product. These items are typically called stories, or sometimes just backlog items. Stories should be written in the language of the customer/user detailing a unit of work that can be completed by the team in a single sprint. The product backlog may have multiple inputs but should be prioritised by a single person, the Product Owner.
- The Product Backlog should contain items that will be worked in the next 12 months
- Stories that are very unlikely to be developed in the next year then they should not be included in the Product Backlog
- This helps avoid cluttering the backlog with items that are very far in the future or may never be developed at all and keeps focus on more immediate targets
- The Product Backlog should ideally contain no more than 150-200 backlog items
- Items in the Product Backlog should be in prioritised order as prioritised by the Product Owner
- Priorities can and will change as conditions change and new information becomes available
- It is not vital that everything is prioritised in exact order, the lower an item is on the priority list the more vague the priority tends to become
- When prioritising items that are lower on the list it’s usually good practice to consider the backlog item in relation to other backlog items of similar priority (e.g. is feature A more or less important than feature B)
- The higher priority and the closer a backlog item is to being added to the sprint backlog the more detail it should have
- Items that are further away from being worked on will typically have less detail, however more detail should be added before an item is scheduled for a sprint
- Larger stories are typically called Epics and should be broken down into smaller stories before they are added to the Sprint Backlog
The Product Owner may also request rough time estimates for backlog items to assist in prioritisation and calculating business value of backlog items.
Sprint Backlog
The Sprint Backlog is a prioritised list of Stories or Backlog items that will be completed in the next Sprint (development cycle/iteration). Stories that are added to the Sprint Backlog should contain enough information for the team to complete the story.
- Stories in the Sprint Backlog should be prioritised by the Product Owner
- Stories in the Sprint Backlog should all have time estimates
- The Product Owner and the Team agree on the contents of the sprint based on the available sprint time and previous velocity
- The team should take into account all known factors for the upcoming sprint period e.g. planned holidays for team members, conferences, public holidays, recurring business as usual tasks etc.
- The Product Owner may re-prioritise some stories based on size and available time to "fill up" the sprint
- Some teams also set aside a percentage of available sprint time for fixing bugs, reducing technical debt and/or refactoring
- Prior to the start of the sprint all stories should have estimates, be clearly prioritised and be broken down into tasks
- Task breakdown is done by the Team during the planning phase
- The Product Owner should not interfere with task breakdown or estimates
Burndown
The burndown chart is a visual representation of the Scrum Team’s progress in a given sprint. It is updated by the Scrum Master every day and allows the whole team and any involved stakeholders to get a quick visual overview of the progress of a sprint.
- Daily progress for a Sprint over the sprint’s length.
- Graphical representation of work left to do versus time.
- Outstanding work is represented on the vertical axis, with time along the horizontal.
- Updated daily by the Scrum Master
- Useful tool for gauging whether tasks will be completed within the sprint or not
Three central rituals or ceremonies in Scrum
- Sprint Planning (Task Breakdown and Estimation)
- Daily Scrum (Daily stand-up)
- Sprint Review (Demo & Retrospective)
Sprint Planning – Task Breakdown and Estimation
In Scrum the "big design up-front" approach is discarded in favour of a smaller units of work where the choice of implementation and solution is often left much in the hands of the team. So instead of providing full, detailed descriptions of how everything in the project is to be done, a lot of this is left up to the team. This is done because the team will know best how to solve its problem. The product owner provides the team with desired outcomes from a user and business perspective rather than suggested technical solutions which is typically not the area of expertise for the product owner.
- Sprint Planning isn’t a roadmap or a strategy discussion.
- Time-boxed to 4-8 hours which is typically sufficient for a 4 week sprint
- The overall theme or focus of the Sprint, and majority of the product backlog scheduled for the sprint should be prepared and and published prior to the meeting
- This is the responsibility of the product owner or the Scrum Master
- The team should have at least a day to review the items in the Product Backlog that are scheduled for the sprint
- The team needs enough time and information to understand what implementing each backlog item would require
- The time reviewing the preliminary sprint backlog should also be used to add technical-driven features for consideration that may be required to support planned features
During the Sprint Planning the team will initially estimate the relative size of each story, typically during a process called planning poker. This process minimises the risk of vocal individuals influencing the estimate and reduces underestimating of tasks. The planning game starts with the Scrum Master or one of the developers with the most knowledge regarding a specific feature providing the team with an overview of the feature and work required. Each team member then places a card with their estimate face down on the table and everybody reveals their estimate at the same time. The highest and lowest estimate then discusses their reasoning then everybody votes again until a consensus is reached.
- Stories are estimated in relative size using "days" or "story points"
- Estimating in relative sizes has been show to be a lot more accurate than trying to use actual or specific units of time
- Tasks are estimated in hours
During sprint planning each story is broken down into multiple tasks. Tasks should consist of all the individual bits of work that will be required to complete the story. During the task breakdown the team typically discusses technical and implementation solutions but may defer final choice of implementation to be decided during the sprint. One of the tasks for that story might then include researching, spiking and choosing an implementation for the story. While the stories are estimated in days or story points, tasks are estimated in hours. The planning game can also be applied to task estimation.
Daily Scrum
The daily stand-up meeting or daily scrum is one of the core rituals or ceremonies in Scrum. This daily meeting gives the team and Scrum Master a daily update on progress, enabling obstacles and potential problems to be identified and dealt with as early as possible before they become real problems. It also enables the Scrum Master to make adjustments to the sprint plan to ensure things are kept on track. This could be reducing the scope of tasks or agreeing with the Product Owner to defer or drop certain stories to ensure that stories with higher priority are completed.
- Same time every day. Keep the meeting at the same time every day. All team members need to attend.
- Everybody stands. Making everybody stand keeps the meeting short and to the point. Any longer conversations should be deferred to after the meeting.
- No longer than 15mins (timed)
- The daily Scrum typically has the following format:
- Done: Each team member states what they have done or achieved in the preceding 24 hours
- Obstacles: Each team member states whether they have any impediments or obstacles preventing them from working effectively on sprint tasks
- To Do: Each team member states what they plan to work on in the next 24 hours
Prior to Scrum all team members should update remaining estimates for tasks. The Scrum Master should then update the burn-down chart so that the entire team gets a clear and visual representation of their progress.
Sprint Review – Demo and Sprint Retrospective
The Sprint Demo
At the end of each sprint the team demonstrates the work completed in the Sprint to the Product Owner and potentially some stakeholders. The demo to the product owner should showcase the completion of each story committed to during the sprint. The demo should make it clear what aspects of the stories are not complete, if any, and what the plan is for getting them completed.
- During the demo it should be made clear which features are unimplemented due to being scheduled for a future sprint.
- This will help avoid questions/concerns from the product owner about those features being missing or ugly.
- If the sprint was done correctly, there should not be any surprises at the demo.
- Acceptance testing should have occurred during the sprint giving the product owner previews of the features to avoid any major changes or unexpected rejection of implementations
Inevitably there will be some minor tweaks suggested by the product owner and/or stakeholder during the demo. The team should only accept tweaks that can be completed during the slack period unless the product owner is willing to sacrifice either delivery date or other release features. Any bugs discovered prior to, during or after the demo should be fixed during the slack period prior to release rather than deferred for later or added to technical debt.
After each Sprint the team holds a Sprint Retrospective meeting. The meeting acts as a self-assessment for the team and aims to improve processes for future sprints. The sprint retrospective should never be used to place blame but should be an objective review of what went well and what did not go so well during a sprint that can be improved. To be a successful and agile team you need to continually improve your work habits and update your process to match changing situations. Retrospectives are a great tool for achieving this. Well that’s it, perhaps not the shortest or most concise explanation but it should give you the building blocks to work with and consider whether Scrum is right for your organisation. Perhaps the most common mistake people make when attempting to use Agile or Scrum is that they don’t commit to the process enough but rather just pick and choose elements that fit with their organisation or previous methodologies. This may work in some instances however more times than not it’ll generate rather poor results and generate a rather poor impression of Agile within the company. To be successful you and your organisation will need to devote both time and resources to learning and implementing Agile well. It’s recommended that you start out following the standard principles of Scrum and avoid large deviations until your team has a few sprints under its belt and are familiar with the principles of both Agile and Scrum. It’s always better to know the rules before you start bending or breaking them.
Summary
Scrum and Agile Development Books
Excellent article with clear explanation!
Really nice overview. You really gave me a nice starting point to do further research from.