There are a number of terms you’ll consistently hear when working with Agile frameworks like Scrum, Kanban or just discussing an Agile approach in general. Here are a few you’ll probably hear the most, but this is really the tip of the iceberg. Lots of companies and teams may have their own naming conventions for the same things, the key to all of this though is everyone has a clear understanding of what the subject is no matter what you call it.
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>.
Velocity In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning. Once established, velocity can be used to plan projects and forecast release and product completion dates.
An Agile framework for completing typically software development projects but can be applied to any product development
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. So how hard is it basically
An iteration of work during which an increment of product functionality is implemented. Our development sprints are typically two weeks and our design sprints are one.
Sprint Planning is typically an hour long meeting for a 2-week sprint planning what the sprint backlog will be
What the Development team and Product Owner want to achieve by the end of this sprint
THE DAILY STAND UP
The Daily Stand Up Typically 15 minutes meeting for the development team to update everyone on what they did the day before, plans for today and any blockers or issues
Sprint review is a time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximise the value of the next period.
Sprint Retrospective is time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint. We usually try to keep these to an hour which should be enough following a two week sprint
SPRINT BURNDOWN CHART
A sprint burndown chart (or “sprint burndown graph”) depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the product backlog items that achieve the goals of the sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours)
All the user stories the development team have committed to in a sprint
Meets the definition of done but it does not mean you have to ship at the end of each sprint, but the code is a shippable quality
The management principle that teams autonomously organise their work. self-organisation happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.
The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner
In Scrum, a single person must have final authority representing the customer’s interest in backlog prioritisation and requirements questions. The Product Owner must be available to the team at any time, but especially during the sprint planning meeting and the sprint review meeting.
A person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.
THE DEVELOPMENT TEAM
The Development Team are made of Engineers, QA, Designers. Any team members who are the doers, so not the Scrum Master or Product Owner
A piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole – form a product.
DEFINITION OF READY
Meets the agreed Definition of Ready (DOR) and means the story can be worked on it a sprint
DEFINITION OF DONE
Meets the agreed Definition of Done (DoD) and means the story can be marked as complete
An artefact is an output from Scrum, so typical artefacts are the Product Backlog, Sprint Backlog, Burn-Down Chart, or Increment (update to the app or web build)
Agile is not a process or tool, it’s a set of values and principles so you can empower the team and meet the needs of others. It encourages the ability to create and respond to change. Further info on the Agile Manifesto here