This lecture focuses on the scrum framework. It bases its learning from the scrum guide which is strongly recommended reference to understand the base principles for scrum. Learn about the structure of the framework and some of the ceremonies that define it.
Big Picture
Scrum Framework
When discussing Agile frameworks, the most popular of these is Scrum, which is derived from the rugby term, it is lightweight and predominately used in software development Scrum was first used by Hirotaka Takeuchi and Ikujiro Nonaka in their guide "The New New Product Development Game." This was aligned to a game of rugby where a scrum is formed where team members work closely together supporting each other. It was formalised by Jeff Sutherland, John Scumniotales, and Jeff McKenna in 1993.
It is often referred to a process framework associated to a clear set of practices and guidelines that are performed within the Scrum itself. The most common word associated with Scrum is Empiricism - working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on real observations.
Scrum Pillars
Generally where words such as transparency, Inspection and Adaption are mentioned in any conversation then the topic is Scrum, and are known as the three pillars. These pillars provide guidance and visibility on the way the framework should direct itself. Each pillar represents either the mindset, the approach and the way things are done.
The three pillars embodies the ethos of scrum. Transparency is often seen as the foundation for Inspect and Adapt, without transparency neither can be done correctly. All areas including the business and scrum teams need to show transparency in terms of the work being done by the teams. trust and openess is vital for this.
Inspection is carried out by the whole Scrum team and progresses towards the sprint goal. An aspect of Inspection can be the Product backlog, the Sprint Demo and Sprint Review. Inspection allows allows the team to communicate the delivery for the product and track milestones and quality.
Adaptation is the action or process of changing something, a good example of this is Backlog grooming and adding stories or acceptance criteria's, Story estimation and prioritisation .
Ensuring that the three pillars feature prominently in the way Scrum is done is vital, it allows oneself to keep to the goals that drive the quality on the product being built and engages the whole team on what need to be done and how.
Scrum Values
The scrum team abide by the 5 core values or competencies, everyone within the Scrum focus on the clear objective - Sprint Goal. All team members work collaboratively using the values to deliver a increment of 'Done'. The transparency of the work by the team ensures that the values can be achieved.
Each scrum members use the pillars and the values to unite on the focus on what is to be achieved, and each agrees on the way to work, improve and address challenges that may confront them. This is the clear essence of Scrum.
Values help in the way the team interacts and the approach that is taken. Each shapes the thought processes around how things are done, and more importantly why we do them,
Scrum Team
The concept around an Agile team is based on Agile principle No 5:
Agile Principle #5
"..Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.."
We are able to embrace this principle around our understanding of the scrum team. The scrum team consists of empirical members who are able to guide each other and have there own area of expertise. They are leaders in their own right, and have an equal role and standing within the group. There is no hierarchy and no leader. Each member of the team works on the defined increment of 'Done'. The whole of the development team is accountable for the delivery .
In most Agile frameworks development teams are described as 'Cross Functional', 'self organised' and 'empowered' teams.
It is vital that the Scrum team are kept to the maximum limit of 9, this is gauged as the optimum velocity a team can perform at it's most efficient.
Having small scrum teams empasises focused delivery allowing highly skilled power teams deliver the product. There are 3 main roles in a scrum team: Scrum Master, Product Owner and the development team.
It is important to emphasize, there is No leader in the Scrum team. The Scrum master or Product Owner is in an equal par as the developer. They're skillsets fit like a glove embracing their collective knowledge and experience motivated towards the team success.
Roles and Responsibilities
The three main roles inside scrum are:
1Scrum Master
The scrum master is the Servant leader where the main goal is to serve.
They serve the development team and also advocate the agile mindset and practices to both the business and the scrum.
They align themselves to remove any impediments or blockers that may arise in the process and actively ensure the facilitation for scrum activities or ceremonies.
Scrum Master is not a bottleneck
In many organisations a scrum master heads up a lot of the ceremonies and communication between the stakeholders and development activities. This is often deemed as a non agile practice.
The responsibility does not lie in the scrum master to do this but falls on the roles of the full development team. The scrum master ensures there is no single point dependency on a person and the team can operate effectively with no impediments whatsoever.
2Product Owner
The product owner is the proxy business representative for the scrum team. They ensure that requirements that come from the business are shaped and understood for the development team to execute.
The Business Vision for the work needs to be understood by the Scrum team so it is imperitive that the Product Owner understands the product, and the needs of the business. The other main tasks for the product owner is to manage and prioritise the backlog
The product owner is the single owner of the backlog, every item needs to be authorised and approved by the PO before it will go into the backlog for prioritisation. Other duties for the Product Owner include
Backlog Grooming
Maintaining the backlog is one of the main tasks for the product owner. Ensuring user-stories are created are accurate and contain acceptance criterias and have clear business value and old user-stories are removed.
Story Mapping
Working with stakeholders to create user-stories are also vital. Having accurate stories enable the development teams to deliver exactly what the user wants. Story mapping is a technique that allows stories to be created at epic level.
Writing user-stories
User-stories are a subset of story mapping - the single unit of a feature to be developed. Generally stories created are based on the behavioural appraoch where customers behaviours are captured in terms of the requirements.
Story walkthrough
Once requirements are captured these will need to discussed with the development teams for delivery.
Prioritisation
Prioritising items from the backlog
Liaise with scrum master
The Product Owner and Scrum master work closely together, particularly during the Sprints.
The Product Owner and Scrum master work closely together, particularly during the Sprints.
3Development Team
The development team are responsible for the execution and delivery of the Sprint. It is here that the emerging detail is defined as increment of 'Done' will be created.
They will translate the user-story into functional and non-functional needs. The developers are empowered to make day to day decisions according to their area of expertise. All sub-tasks for the user-story are created, all dependencies are defined and all test documents are prepared during the Sprint.
The Development team consists of Developers and QA testers. I have also included the Business Analyst (although the role has not been stated in the scrum guide), this is because they are a key dependency during the Sprint to support the team.
Scrum milestones
There are two key milestones used by the Scrum teams, one is to ensure the team is committed to accept user-stories in to the Sprint backlog that are fit for delivery - this is known as D-O-R (Definition Of Ready). The other milestone is around "what is done and how is it defined."
Definition Of Ready (D-O-R)
This is a list of caliborative tasks that should be completed for a user story to accepted in to the prioritisations items of the backlog. It is generaly the product owners role to ensure the stories are in D-O-R state, ready for the development team to prioritise or deliver. It is the job of the scrum master or development team to ensure that the user-stories are fit in terms of D-O-R, ready for execution.
Generally, user-stories not in D-O-R should not be priortised into the Sprint backlog. The type of criteria that is stated in the D-O-R is as follows:
Definition of Ready (D-O-R)
- 1. There is a valid Business Case
- 2. Delivery date captured from stakeholder
- 3. User-story sign off from business
- 4. User-story has correct format (As a - I want - So that)
- 5. User-story has acceptance criteria
- 6. User-story has had a walkthrough
- 7. User-story must be estimated
- 8. User-story has testing tasks assigned
- 9. User-story non functional tests assigned
This format will ensure that any user-story developed by the Scrum teams has a commit value from the stakeholders, the business and the development team.
Definition Of Done
One of the most common issues that arise from software development is software bugs, poor quality coding, functionality not meeting user requirements. Scrum takes an approach where we define what 'done' looks like, in the form of Definition of Done (D-O-D). There are two levels of D-O-D, at feature level and at product level.
As a collective, the business and Scrum team define what D-O-D should look like, this often involves some outside technical authority such as technical architect. Once this has been agreed, all software developments are measured on this accordingly, with the objective of adding it to a release and part of the product increment. These guidelines ensures that the product is stable and technical fit for purpose.
Definition of Done (D-O-D)
- 1. Feature has passed all acceptance criteria
- 2. Feature integrated into clean build
- 3. Feature has no bugs or defects
- 4. Feature passed all regression tests
- 5. Feature has been code reviewed
- 6. Feature has tested all non functional requirements
- 7. Feature passed integration tests
- 8. Feature promoted and tested Pre-prod environment
- 9. Feature is supported by relevant documentation
Scrum ceremonies
There are 4 main ceremonies in the scrum
Before a sprint can start, prioritised items from the Product backlog are discussed with the development team and are then agreed to put into the Sprint Backlog based on availablility and capacity. The objective is to agree the work to be committed during the Sprint and agree on the Sprint Goal. All scrum team members attend and discuss what will be delivered and what will be achieved..
Daily scrum or 'Stand-up' is a daily activity that is timeboxed for 15 minutes to ensure the goal for the sprint. This is on-going for the full duration of the Sprint. The facilitator for this can be any member for the development team. The scrum master does not need attend. There are three main questions asked at the start of the stand-up.
"... What did you do yesterday ..." "... What do you plan to do today ..." "... Are there any impediments or blockers ..."
This is chaired by the Product Owner. The sprint itself ends with the Sprint Review. The Product Owner goes through what has been achieved during the Sprint for all the 'Done' items. This is then followed by a Sprint Demo of what has been created.
This is chaired by the scrum master. Once the Sprint Review has been completed, a Retrospective meeting is followed. This is where all members of the Scrum talk about what went well during the sprint, and what they could have done better. All findings and actions are recorded in the Retrospective log.
Prioritisation Meeting
Once user-stories have been created and in D-O-R status, they can be prioritised accordingly to decide which priority items the scrums should work on during the sprint. Prioritisation normally happens few days before the sprint is due to start. Product owners will set up an prioritisation meeting, this will involve relevant stakeholders, business reprsentatives and relevant heads, here estimated priority items are discussed and the priority order decided and user-stories tagged.
It is usual to apply a 80:20 parato rule for items in the sprint backlog, therefore, the product owner will be mindful that some contingency needs to be applied to the workload. So bulk of the items prioritised will be about 70-80% and will be deemed as the must haves
It is vital the Product Owner has a groomed backlog in order to ensure that no priority work is left out, the backlog must also be ordered with th last priorities defined by workshops that may have arised up to the point of prioritisation.
Once priorities have been committed then prioritised items can be committed to the sprint backlog based on the capacity of the scrum team.
Sprints
These are timeboxed events which starts off with a goal and ends with a commitment or an objective that has been met. These timeboxes are based on fixed time and fixed costs, only the scope of what comes into the sprint can be compromised. The objectives form the deliverables for an increment of 'Done' in terms of the Definition of Done. Based on Agile principle No 5 this personifies the nature of a sprint to deliver software frequently.
Agile Principle #3
".. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale .."
The Sprints run sequentially, and a prioritisation meeting occurs before the kick off. Sprints run sequentially one after the other, there is no break in between. Here the emerging detail is shaped and executed by the scrum team members. In principle once the sprint has been committed no items should be added. Only scope can be re-negotiated.
The duration of a sprint is generally from 2 weeks to 4 weeks, anything longer is deemed to slow down the rate of development and reduce the predictability of scrum events. The structure of a sprint is shown below:
The diagram above describes where the scrum ceremonies discussed earlier sit within the sprint. During Sprint planning the Sprint Goal has been created, this objective is accepted by the scrum team and focus will be maintained to achieve this. In the early phase of the sprint user-stories committed as a result of the sprint planning are being understood by the team, any gaps uncovered are resolved quickly, sub tasks created to show some transparency on the work to be done on the analysis or development started. For effective monitoring all team members log the time start on all activities and when they finish. This will help the scrum master understand the work remaining.
Conceptually, sprints can be split in to 3 parts sprint execution, Integration and finally QA, the diagram below shows the main structure of some of the high level activities during the sprint and the scrum team members involved.
Scrum Artifacts
These are information radiators to visualise the work to be channelled to the development team in the shape of the Product Backlog, Sprint backlog, Product Increment and the Burn-down Chart.
Product Backlog
Here the work is conceptionalised and shaped in the form of requirements or user-stories. Backlog is not a wish list, it is a approved list of requirements that have been shaped for the business stakeholders, by the Business Analyst or the Product owner. The Product backlog items are prioritised at any opportunity, with the most highest on top. The objective is to pull items from the top of the list for the development team to work on which have the highest business and economic value.
The backlog is owned by the Product Owner, he has total authority over the contents for the backlog and any items moving in need to be authorised by them.
Every user-story in principle should be aligned to the business vision or strategy, this ensures that there is value and importance to what is to be delivered.
Sprint Backlog
The sprint backlog are items to be worked on by the scrum team during a sprint. The owner is the development team. During Sprint planning sessiop they discuss the prioritised items and commit to delivering these items during the sprint. Items are then pulled from the backlog into the Sprint Backlog.
The development team decides which items they would begin to work on. There is no pressure on the development team to start any task. They are responsible and accountable for the delivery for the work.
Product Increment
The Product Increment is the the sum of all work completed during the Sprint and previous Sprints to the definition of Done. The Sprints enhance the transparency of the increment. The increment is the next step to the goal. Most organisations build their product features according to product increments rather than sprints. This allows the visibility towards a working software solution.
Burndown Chart
During the sprint the total work remaining to reach the Sprint goal is calculated using the Burndown Chart. The Product Owner uses this chart to determine not only the effort remaining and whether the intended target will be met, but also determining the velocity of the sprint based on previous historical sprints.
Agile Principle #10 "..Simplicity the art of maximizing the amount of work not done is essential.."
The burndown is a good visual indicator of the work remaining during the sprint and the whether the team will achieve the intended target for the sprint goal. Any user-stories that have not been completed are termed as 'Spill overs'. The burndown chart is very god indicator as to whether the team is on track - but there is a strong emphasis on the scrum team logging the time recorded in order to keep the track up to date.