A High-Level guide to Scrum frameworks in software development

Scrum Artefacts

There are three artefacts within scrum, The Product Backlog, The Sprint Backlog and the Increment

The Product Backlog – a prioritised lists of work (epics, stories and tasks) that could be done for the product. The product back log is managed by the PO and is the single source of work for the development team.

The Sprint Backlog – a list of work (stories and tasks) identified during the sprint planning to deliver the sprint

Increment – A list of the work delivered in the sprint and all the previous sprints which make up the delivery for the product.

The Main Players in Scrum

The Stakeholders, The Product Owner, The Scrum Master, The Scrum Development Team

The Product Owner (The PO)

The Product Owner (The PO) Accountable for the product backlog

The business representative responsible for defining the work on the scrum development team

The bridge between the business stakeholders/the customer and the scrum development team

The PO will help define the epics and stories to be delivered to complete the product (The Work)

The PO is responsible for planning the work with the scrum development team and agreeing the sprint deliveries to complete the project. 

The PO defines the priority of the work to be done inline with the stakeholders and communicates this to the team to make sure the highest priority items are worked on first.

The Scrum Master

The Scrum Master Is responsible for the scrum development team following the scrum framework and running the daily scrum meeting

Responsible for the scrum development team working efficiency

Responsible for the smooth running of the delivery, adding tasks to deliver each story including environments and removing blockers to the team.

The Scrum Development team

The Scrum Development team is normally a cross functional team utilising all their skills to complete any task which needs to be done.

•The team is self managed and share responsibility for the delivery of the sprint.

•The team often has its own test resource so to complete sprints ready for review.

Scrum Framework Meetings

Meeting 1

Vision: This stage involves discussions with stakeholders (commercial teams, customers, etc.) to define the overall product vision and goals.

Epics and Stories: The product owner gathers and translates the vision into epics and stories for the product backlog. Measures are captured based on the business need, priority, and risk.

•Typical format: “As a [user role], I want [goal] so that [benefit].”

Meeting 2

The product owner and the scrum team, discuss the prioritised epics and stories from the product backlog. Measures are captured for each story based on story points which represent time across the scrum team.  (i.e. 8 points could represent 8 hours of a team resource)

In Jira, create a Sprint and add the selected Epics and Stories (This is the Sprint backlog)

For this example, the sprint window is a two-week cycle, so a list of stories from the epic are identified as deliverable within that time.

Tasks are added and linked to the story

Tests are added to the story and assigned to members of the scrum team

The team focuses on delivering a potentially shippable increment of the product by the end of the sprint.

Meeting 3

•The product owner respond back to the stakeholders with an updated product backlog and sprint backlog detailing the stories and epics for the next product increment.

•The schedule is updated to deliver the complete product vision

Daily Scrum Meeting

In the daily scrum meeting each team member discusses what was completed yesterday and what they are working on today.

•The developers works on the code for the story in the sprint backlog.

•The test team add test cases which cover testing the story. Defects are created and linked to the test case and discussed in the daily scrum.

•The tasks are added and assigned or resolved by the scrum master, these include test data and test environment.

•All team members work together and take responsibility towards the team’s goal to deliver the project. Working well this method leads to an efficient structure,  agile enough for complex daily deliveries of stories identified for the sprint.

Sprint Review Meeting

•The sprint review is informal and allows for feedback from the product owner and the stakeholders. The new stories are demonstrated to ensure the product meets the vision. Feedback is gathered and used to refine the product.

•At the end of each sprint, the team holds a retrospective to identify areas for improvement in the process. Identify what went well, what didn’t go so well, and allow the team time to reflect on and adapt internal practices where needed.

•Each sprint results in a shippable increment, meaning the product is in a state where it could be released to production.