Agile & Scrum

Projects at Trew Knowledge follow an agile approach, typically following the Scrum framework. This helps us move faster and work together better as a team while ensuring developers can get work done without constantly being blocked. Once the team has decided on what will be worked on and how it should go about it, the team is empowered to deliver the work in the way they see fit. This means that the team is responsible for the delivery of the work and for the quality of the work. With that great freedom, though, comes equally great responsibility. When you are on a Scrum team, we trust that:

• You can problem solve - User stories won’t have technical details on how to do things. It is up to the team and the Tech Lead to interpret the requirements and develop solutions.
• You will commit to the whole goal of the sprint.
• You will do all in your power to meet your commitment.
• You will work together to meet the commitment.
• You will communicate if unforeseen circumstances alter what you’re able to deliver.

​

“Who”: The Participants

Scrum is based around a small group of cross-functional team members working to deliver results. They have specific, named roles in the scope of the project:

• Product Owner (Key stakeholder)
• Project Manager
• Technical Lead
• Developers
• QA Analysts

​

Product Owner

The Product Owner (PO) is the key stakeholder on the project. They are responsible for gathering requirements with the client and putting together the user stories with those requirements and acceptance criteria. They are also responsible for prioritizing the backlog and ensuring the team works on the most important things first. In most cases, a main stakeholder on the client’s side can work closely with the Product Owner to align on requirements and expectations. This stakeholder will have a deep understanding of the product and its users and will be able to provide the team with the necessary information to build the product. The product owner is responsible for clearing blockers, gathering additional information, answering questions, and supporting the Tech Lead and developers.

​

Project Manager

The Project Manager’s main responsibility is to ensure the project is moving at an adequate pace and that the timeline is protected. They provide reports to the client regarding timelines, budgets, and progress. The project managers are also responsible for scheduling meetings and sprint demos, presenting progress and statistics, ensuring the team is on track, and ensuring the client is happy with the progress.

​

Technical Lead

The Technical Lead is responsible for the technical direction of the project. They are responsible for ensuring the team is working on the right things and in the right way, that it is sustainable and scalable, and that it is working in the right way. Tech leads work very closely with Product Owners when refining user stories. They must understand all of the requirements and acceptance criteria and are responsible for breaking those into sub-tasks for the developers to work on. Tech leads are the developers’ main point of contact when they have questions or are unsure how to proceed with a task.

​

Developers

The developers are responsible for building the product. They are a group of dedicated individuals capable of working across disciplines who are team-focused and results-oriented participants in the process.

​

QA Analysts

The QA Analysts are responsible for ensuring the product is of high quality, meets the acceptance criteria, and is of a high standard. They will test tickets against the acceptance criteria and provide feedback to the developers. They are our last line of defence before the product is delivered to the client.

​

“What”: Scrum Project Lifecycle

When we start a new project, there is a lot of work to be done before we can start writing code. It usually involves a discovery phase, a strategy phase, a design phase, and a development phase. As a developer, you will be more involved in the development phase. Once development has started, the project revolves around Sprints and their associated events. These are typically two-week blocks of development time, and they repeat until the project backlog is complete.

​

User Stories

The product owner will work with the client to gather requirements and create user stories that meet all the acceptance criteria. These user stories will then be presented to the client for confirmation and sign-off. Once we have the user stories, the product owner and the tech lead will work together to refine the user stories and break them down into smaller tasks. This is a crucial step as it will help the developers understand what needs to be done and how to do it.

​

Backlog Refinement

The Backlog is an ordered list of all the features that need to be included in the project. It is also a dynamic list, responsive to the project’s evolving needs. The Tech Lead will book a meeting with the developers to discuss the user stories and acceptance criteria. This call is to discuss and present what we’ll be working on and get everyone’s input on how to approach the tasks. During this call, the Tech Lead will also guide the team on how to estimate the stories using Planning Poker.

​

Estimating with Planning Poker

We use Story Points for our estimations. It is essential to understand that Story Points are not relative to time but rather the complexity of the task. We use the Fibonacci sequence to create points of comparison (typically 1, 2, 3, 5, 8, 13). After presenting a User Story, the tech lead will initiate a voting session where everyone will anonymously vote on how many points they believe the story is worth. The team will then discuss the differences in votes and re-vote until a consensus is reached. We have a Slack app integration for this purpose, which allows us to vote and discuss the story points without revealing our votes until everyone has voted.

​

Sprint Planning

Well before a sprint begins, a Sprint Backlog is created. The Sprint Backlog is a smaller list of stories taken from the top of the Product Backlog that the development team has committed to and designated to be completed in the Sprint. Sprint planning usually happens at least two sprints ahead of time, which includes:

• Capacity Update
• Issue Review
• Velocity Prediction
• Team Buy In
• Team Commitment/Agreement

Goal: to plan work for the upcoming sprint/s, outline priorities, account for capacity changes, and commit to deliver

​

Sprint

A sprint is the basic unit for development. It’s timeboxed, which means it has a restricted unit of time and can act as a subproject within the wider development project. The parts of a sprint are:

• Get to Work
  • Build
  • Test
  • Review
  • Release
• Communicate Issues
• Risk Management
• Complete

A typical sprint is two weeks long.

​

Standup

The daily rhythm of a sprint includes a regular, short check-in meeting called a Standup. In this meeting, led by the Project Manager, the team reports on the following three questions.

• What have you done since the last Standup?
• What will you be working on today?
• Are there any blockers you need help with?

No code debugging should be discussed in this call. This is a quick status update to give everyone an idea of what everyone is working on and if there are any blockers. Developers are free and encouraged to connect throughout the day to discuss and solve problems, but the standup is a timeboxed meeting to ensure everyone is on the same page.

​

Sprint Demo

The Sprint Demo happens at the end of a sprint and demonstrates to stakeholders what has been completed in the most recent Sprint.

• Showcase completed Work
• Review/Report on Burn-down and Velocity

​

Sprint Retrospective

The Sprint Retrospective happens once per sprint and is an opportunity for the entire team to come together and evaluate what went well and what needs improvement. The aim is to produce action items for the team to help them increase the efficiency of succeeding sprints.

• Celebrate Success
• Review Failures
• Resolve to improve together

​

Repeat!

The Backlog Refinement, Sprint Planning, Sprint, Sprint Demo, and Sprint Retrospective steps are repeated constantly until the project is complete and the backlog is empty.

​

“Why/How”: Rationale and Practice

The above outlines the framework but doesn’t wholly cover the actual, practical application.

​

Communication

One of the keys to the Scrum process is communication and transparency. This happens through frequent communication, often in the form of meetings. This communication provides mechanisms for the Product Owner and Development Team to discuss, plan and execute the development of working code. It also provides a mechanism for learning, improving, and iterating on previous work. An initial backlog refinement is held before the first sprint, generating enough issues for the first three sprints. (Ready for refinement means the Acceptance Criteria are complete.) Each sprint has a number of regular meetings; for a 2 week long sprint: Stand-up: Daily, 15 mins Backlog Refinement: Weekly, 1-2 hours Estimating (Planning Poker): Weekly, 1-2 hours. Can be merged with the refinement meeting. Sprint Planning: Once per sprint, 1-1.5 hours. Planning for the next sprint and beyond (not the current one). Sprint Demo: End of the sprint, 1 hour. Sprint Retrospective: Once per sprint, 30 mins-1 hour. Conducted after the Sprint Demo. At first glance, this may seem like a lot of meetings. However, it’s important to note that these replace ad hoc, haphazard meetings with regularly scheduled meetings. Plus, as the team gets more efficient and the backlog is nearer completion, you may find you need less refinement and estimating. But all meetings are important to the ongoing improvement and velocity of the sprint; they remain fairly critical to delivering the product.

​

Predictability

One of the tenets of Scrum is the inviolability of the Sprint: once a Sprint has begun, it isn’t changed. One of the jobs of the Project Manager is to protect the sprint from outside interference, changes, and challenges. Sprint planning, refinement, and estimation provide a mechanism to estimate effort, learn how much effort the team can expend in a sprint, and, as a result, try to predict velocity. We can take that projected velocity, mix it with availability and other known commitments, and deliver to the client or Product Owner a more reasonable expectation of what can be anticipated in terms of deliverable software and/or release planning. During sprint planning, the team commits to the sprint goals and works toward them; the Project Manager deals with the obstacles that life, clients and the universe put in the way; and ideally, at the end of the sprint, the work committed to is completed and demonstrated. In cases where circumstances alter what the team thinks they can reasonably deliver against the sprint goals, the Project Manager communicates that to the Product Owner, and the team regroups and revises the commitment. As continuous improvement is a goal, learning from these moments of failure to deliver is important so that the risk of “missing the sprint” is minimised in future sprints.

​

Continuous Improvement

The process of Scrum helps facilitate continuous improvement, mainly through sprint meetings. Each sprint is constantly reviewed, and practices that aren’t working are altered and proposed for the next sprint. Each successive sprint should be able to identify areas for improvement in velocity, predictability, and the ability to deliver the goals. Stand-ups and Retrospectives are instrumental in this, aiming to remove impediments and improve the process and delivery.