Agile Terminology

Agile terminology provides a powerful set of tools for easy communication. To help you master these tools, you can find the explanation of common Agile terms below in our Agile dictionary.

what is agile • backlog refinement • burndown chart • daily • DevOps • epic • MVP • product backlog • product owner • scrum • sprint • sprint backlog • sprint goal • sprint planning • sprint retrospective • sprint review • story point • stretch goal • transparency • user story • velocity

Agile is a set of attitudes and behaviors, a mindset that puts the focus on developing working software, working in close collaboration with the customer, creating frequent iterative increments, delivering value from the start, supporting cross-functional and self-organizing teams, enabling short feedback loops, adapting and taking advantage of changing requirements and focusing on quality from the start.

Agile is a response to complex environments requiring complex solutions where waterfall approaches fall short.

4 initial Agile Software Values are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

While the items on the right still hold value, the items on the left are valued more.
Later on, the 12 Agile Principles were added to provide further guidance to the Agile Values.

Our Agile Coach Bram De Block also wrote an interesting blogpost on why Skyline became Agile.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

Example: During the backlog refinement event, the PO sits together with the main stakeholder to refine the user story related to the creation of a driver for the Nevion NX4600 by splitting the story into smaller tasks, sorting these tasks by their priorities, listing the required parameters, adding story points, estimating the business value, confirming if a Nevion device is available for quality testing, etc.

A burn down chart shows the amount of effort remaining versus time. Typically, in a burn down chart, the outstanding effort is often on the vertical axis, with time on the horizontal one. It is useful to predict when all of the work will be completed, and to visualize the encounter of obstacles to be taken care of and the impact of added features. 

Burndown chart

A Daily or Standup is a daily 15-minute time-boxed meeting for developers to plan their work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily, and forecasting upcoming Sprint work. The Daily is held at the same time and place each day to reduce complexity.

DevOps is a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several aspects of DevOps come from Agile methodology.

An Epic is a large body of work that is usually broken down into smaller User Stories (see User Stories definition). Where User Stories can usually be dealt with in one sprint, an Epic usually spans across multiple sprints.

Example: As a user I want to be able to book my OB trucks for certain times, and when I create such a booking I want the availability of all resources related to that OB truck and necessary to broadcast a live sports event to be checked automatically.

A Minimum Viable Product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.

Example: In his blogpost, Lander Vanhaverbeke from the Nucleus squad describes how they are implementing a first MVP for dynamic units in Data Display in DataMiner Cube.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is accountable for the Product Backlog, including its content, availability, and ordering.

At Skyline, we use Project Collaboration to create and manage the Product Backlog.

The Product Owner is responsible for maximizing the value of the product resulting from work of the development team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

At Skyline, the Product Owner (PO) builds bridges between the development team working on the project and the internal and external stakeholders. POs are accountable for optimizing the value created by the development teams. They maintain close communication lines with end users, know the product vision and can deliver that vision to the development teams.

"The Product Owner makes sure the development team builds the right thing; the development team builds the thing right."

Scrum is a framework in which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

A Sprint is a time box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment.

The Sprint Goal is an objective set by the whole team to provide guidance on why they are building the next increment.

Example: This sprint exists in order to create a user interface where users can run tests with the push of a button to analyse the health of their DataMiner System

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. 

Sprint Planning addresses the following topics: Why is this Sprint valuable? What can be done during this Sprint? How will the planned work get done? 

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, processes, and tools.
  • Identify and order the major items that went well and potential improvements.
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

A Sprint Review is held at the end of each Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders discuss what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

A Story Point is a relative unit of measure, decided upon and used by individual teams to provide relative estimates of effort for completing requirements.

By design, stretch goals are aggressively ambitious, aiming for results radically beyond your current capacity and output; not asking everyone to work harder and longer hours.

Under the right conditions, a stretch goal will inspire a new level of commitment, effort, and performance.

Transparency is achieved when all observers share the same understanding of what is being shown.

Example: When looking at the board of any squad on Project Collaboration, everyone will come to the same understanding as to what the squad is working on, the progress it has made, what is next in the pipeline, etc.

In software development and product management, a User Story is an informal, natural- language description of one or more features of a software system. User Stories are often written from the perspective of an end user or a user of a system. They are often recorded on index cards, on Post-it notes, or digitally in project management software. Depending on the project, User Stories may be written by various stakeholders including clients, users, managers, or development team members.

Examples:
As a DataMiner operator, I want to be able to have human readable parameter values by having DataMiner apply dynamic units conversion to extremely large or extremely low values.

As a DataMiner administrator, I want to be able to configure redundancy for my devices so that when the main device malfunctions, the backup device automatically takes over to guarantee my video stream never gets interrupted.

As a DataMiner operator, I would like to have a panel setting that will ensure that if a parameter value exceeds the 8-character limit, only the First 8, Last 8 or First 4 + Last 4 characters are displayed.

As a DataMiner operator, I want to have the ability to add a 2110 device in the element interfaces in order to monitor its element state easily.

As a user, I want DataMiner to create a booking as soon as I approve a job.

Agile User Story

Measure of work that can be completed in a certain timebox. Usually measured in amount of Story Points. The velocity is calculated by looking at empirical data of previous timeboxes and can be used to make short-term predictions for the future. 

SOURCES

https://agilemanifesto.org/

https://www.batimes.com/articles/from-the-archives-user-stories-and-use-cases-don-t-use-both-d45/

https://www.agile-scrum.be/whats-great-scrum-methodology/user-stories-important-agile/

https://www.techopedia.com/definition/27809/minimum-viable-product-mvp

https://www.scrumguides.org/scrum-guide.html

http://radar.oreilly.com/2014/06/revisiting-what-is-devops.html

5 thoughts on “Agile Terminology”

  2. Ben Vandenberghe

    Great summary overview, very handy. Many times you read about something once, but that doesn’t mean the true meaning of it really sticks. So very useful to always be able to quickly go back to the essence of things, and reconsider if we truly comply with it.

  4. Bruno Dias

    Working through User Story makes a different when it comes to development.
    With this structure, the context and the problem that we are trying to solve becomes much more clear!! Thanks for sharing.

Leave a Reply