Within the Virtual Learning Environment Team we use a set of methodologies termed ‘Agile’ and a specific framework termed ‘Scrum’. Below is a list of terms we commonly use and what they mean.

Alternative names are listed in parentheses, italics are used for clarification.

There are a lot of terms listed below. Please don’t be too concerned by this. It will take time for these to become familiar.

Backlog

A backlog is the list of requests (be it features or bug fixes) that clients and stakeholders would like changed within the product.
The backlog is created so everyone can see what changes for the product have been requested. It acts as both an authoritative list of requests and a public document of what changes are desired.

The backlog is made up of Stories and is prioritised (from most to least) in order of Business Value (see below) by the Product Owner/s. This is done to ensure that the development team isn’t left to decide the importance of feature requests and bug fixes themselves.

Business Value

Business Value is the term used to describe what order Stories in the Backlog should be prioritised in. Business Value does not mean ‘greatest profit’ or ‘highest monetary value’. It is what ever is most important for that business. In the case of most it will eventually result in ‘greatest profit’ as they will be money oriented. If money is not the goal then Business Value will be what ever is.

Daily Standup

The Daily Standup is a Scrum term for a 10-15 minute standing Team meeting at the beginning of every day. Each Team member is asked to answer three basic questions: What did I do yesterday? What am I doing today? What Impediments do I have?; Each Team member answers the three questions in turn. The questions are not for the benefit of the Team’s manager (or Scrum Master) but for the Team itself. This allows the Team to know what each other is doing, help each other out (sooner rather than later) and keep up with their progress.

The Manager or Scrum Master is expected to be present and their job is to take not of any Impediments and remove them as soon as possible so that the team can continue being productive.

Done

Done means done but more importantly it is listed here to give emphasis on ‘Done’ versus half-complete. When the team agrees to add a Story to an Iteration they are agreeing to fully and totally complete the Story. This means not just writing the code but also complete testing and documentation. The Story must be demonstrable to the Product Owner (and any others who wish to view it) at the end of the promised Iteration.

This means that comments like “it’s done, except for” or “well it’s technically done” are not acceptable. This is a part of the contract made each Iteration.

Impediment

An Impediment is something that is blocking a Task from being completed. It is the job of a Scrum Master (or manager) to remove Impediments as quickly as possible so that the team can continue with their commitment. This is a part of how a manager ensures the teams productivity.

Iteration (Sprint)

An Iteration (or Sprint in Scrum terms) is an essential part of this methodology. It is the block of time allocated to fulfill a promised set of work. The typical time for an iteration is two weeks (10 working days). Once the time period has been set it is rarely (if ever altered) and not without good cause. This helps make reporting and prediction about the teams ability to perform (amount work/time) can become much more predictable.

An Iteration is the most basic part of the work cycle. Once a set of work is committed to it cannot be changed during that Iteration. This allows the team to focus on what has been committed to. By making the Iteration a short period of time the Product Owner and client (through the P.O.) can both be certain of what they will receive and when without giving up flexibility in being able to change direction. Direction is only set for the next two weeks.

Iteration planning and review meetings (Sprint planning meeting)

An Iteration planning meeting is used to plan the next Iteration. At this meeting the Team will meet with the Product Owner to decide what should be included in the next Iteration. The Product Owner’s job is to prioritise the Stories in the Backlog (Stories are not removed unless they are completed) and negotiate with the Team what should be included. The Team provides estimate on how long it will take to complete the requested work and how much they can commit to in this Iteration.

An Iteration review meeting is used by the team to self-critique their last Iteration, consider what Impediments arose and possible solutions to things that weren’t temporary and how to avoid them in the future.

Product

The Product is the thing that the Team works on. Although this set of ideas was derived from software programming where a product can be fairly clearly defined it is not limited to this space. With the Virtual Learning Environment the Team is responsible for up to a dozen separate products, some built in house and some proprietary. Since the Team is responsible for all of these the ‘Product’ is the VLE. Anything that the Team works on within the VLE is a part of the Product.

Product Demo

At the end of each Iteration the Product is shown (in working fashion) to the Product Owner and anyone else who would like to attend. This is called the Product Demo. This allows the Team to show exactly what has been completed and is important both in showing the Product Owner what clear progress has been made and in the Team proving completeness of the Iteration’s commitment (see Done). It also gives the Product Owner to see the new state of the Product and allows them to make any decisions about prioritisation for the next Iteration. As such it should come before (possibly the day before) the Iteration Planning Meeting.

Product Owner

The Product Owner is a representative of the Stakeholders. The Product Owner is needed to be able to decide what within the Backlog is most important through to what is least. This is an extremely important role as this decides how much impact the teams efforts will have. If the Team has a good set of Stories to complete then the each Iteration will have a valuable positive impact on the Product (and it’s Stakeholders). If the Stories add no value to the product then the Iteration is effectively wasted effort. As a result the Product Owner has to faithfully and honestly represent the best interests of the Product in terms of Business Value (and nothing else).

Scrum Master (Scrum specific term)

Scrum Master is a Scrum specific term. In other methodologies a manager might take this role. Within Scrum the Scrum Master is not the ‘leader’ of the Team but much more importantly is there to ensure the Team remains productive. This includes removing Impediments, helping if necessary, making sure events (such as the Iteration meetings) happen. In some teams this role rotates between members in others it may be an established position such as the Manager or Team Lead. What remains important is that the Team doesn’t answer to the Scrum Master (they are accountable to themselves and the Product Owner) but that the Scrum Master helps them stay efficient and helps them extend themselves.

Stakeholders

In Scrum these are also referred to as Chickens. This is not an insult but a reference to a joke (look it up on google: ‘Scrum chicken pig’). Stakeholders are all those who have an interest in the Product but are not solely reliant on it. In effect this means that although they have a stake if the Product was to fail or become unavailable this would not be a complete disaster for them. They could recover. This is considered to be different to the Product Owner and Team who are committed to ensuring the Product is delivered and face more dire consequences if it isn’t.

Story

A Story is an extremely important part of this process. This is the description of some need in the words of either the Product Owner or a Stakeholder. This means the Story is not technical and is worded similar to a story or desire that needs to be met. As a result the underlying need can be understood by anyone looking at the Story.

An example of a Story for a reservation system would be:
As a holiday maker I want to be able to see pictures of the hotels I can book so I can see what the rooms are like.

This describes several key things to everyone involved. Who’s need are we meeting (the ‘holiday maker’ or end user). They want pictures, but they want the pictures to see what the rooms are like. This implies that pictures of the view are necessary and that the pictures have to be of a size that the rooms can be seen well.

There is no technical language in this Story but it conveys the need. It is then up to the Team (upon committing to fulfill the Story) what technical details are needed to meet the Stories outcome.

It also automatically creates a test case for the Product Owner, Team and anyone else to use to determine if the need has been met.

Story Points

A Product Owner sets the priority for each Story. This orders the Stories by business value, however the Team uses Story Points to decide how much effort a Story will take to complete.

If for example they are willing to commit to 70 Story Points in an Iteration and they estimate that a Story is 20 Points in size then it will take almost a third of that Iterations time to complete.

Story Points are used to deliberately avoid the use of time, money or any other absolute scale. This has been done because it has been found to be more accurate Teams to judge Stories relative to each other. Over time this results in the Team be ever more accurately able to predict the amount of work they can commit to and the amount of work any particular Story may take.

Task

Tasks are the items a Story is broken into once it is committed to in an Iteration. Once the Story is committed to the Team breaks the Story into individual Tasks that can be accomplished in smaller individual portions. A Task may contain technical language but is only important in telling the Team what needs to be accomplished. A Story is not complete until all Tasks have been finished.

By breaking each Story into Tasks the Team can have more than one Team Member working on individual parts of the same Story at the same time.

Tasks can be assigned in different ways. Some Teams may elect to assign Tasks while other may wish to make the Tasks available and Team Members select Tasks they want to do. In both cases however it is the responsibility of each Team Member (and thus the Team as a whole) to ensure that all the tasks are completed by the end of the Iteration.

Team

The Team is general made up of 4-8 members. These are not necessarily all programmers and are who ever is needed to perform the work. Often Team Members may be cross-functional and include Testers, Database Administrators, Systems Architects and whoever else is necessary.

The Team is responsible for delivering the promised work which means that they are also responsible for deciding how much work they can deliver and how much effort each request will take. This is more accurate and reliable as it will reflect the capacity and skills of the Team that will fulfill the request as opposed to a third party that will have different a different skill level and a different understanding of the request.

Time boxing

Time boxing is a key concept in Agile in general. Although not necessarily referred to in isolation Time boxing is used on most if not all activities within the Scrum (and Iteration type) Methodologies. Time boxing refers to limiting thing to a set or maximum amount of time and being absolute about it. As a result Iterations are limited to (generally) two weeks and the Iteration ends when the two weeks is up, regardless of whether the promised commitment has been delivered. This means that the if promised commitment is not delivered the Iteration is considered a failure. Similarly Iteration Reviews, Product Demos and Iteration Planning Meetings are all limited to set amounts of time. Generally as these meetings can be expected to be large the absolute maximum time is 4 hours though less is preferred. Daily Standups are limited to 15 minutes.