If you are new to Agile, or still thinking about moving to Agile methodology, this is your resource to get all the terms right. Of course this is not an exhaustive list, but this pretty much covers everything. I have tried to cover some of the most commonly used terms. If you don’t find what you were looking for, just give me a shout in the comments below!
Photo by Eric Lefevre-Ardant
Agile project management
This is the terminology used for project management using Agile methodologies. So, the style of project management which aides agile activities like daily standups, dynamic scope, collaboration among the stakeholders, continuous integration and availability of working product etc. can be called as Agile project management.
A backlog is a collection of user stories and tasks that the team needs to work upon in future. The future may sometimes even mean the current sprint or upcoming sprints. Backlog can be classified as product backlog and sprint backlog. Product backlogs are related to the tasks to be done for the overall product while sprint backlogs are the ones that need to be completed in the current sprint.
Continuous integration is a key attribute of products developed via agile methodology. But as is the human nature, developers may sometimes make mistakes and inadvertently commit bugs to the software repository. When such a commit stops the build/compile process or causes unacceptable warnings or failures in the automated test environment or a combination of these, the build is said to be broken. The developer is said to have committed a build breaker. It is generally a priority to get the build to normal as soon as possible and the responsibility for this lies with the developer involved.
This is a graphical representation of the work remaining to be done versus the time available. This can be a great motivator if the team makes steady progress and hence it should be shown prominently in the project management tool.
Agile methodology says a user story must be independent of other user stories. In a broad sense, there should not be dependency on whether the other stories are implemented or not. But, many times, real world scenario differs. There can be a scenario involving several dependent features and so the concept of epic stories was brought. An epic story can be defined as a large undefined user story that needs to be broken down in smaller pieces before it can be used. Read in more details here.
If something is going in the wrong direction, it is important to track and stop it as soon as possible, instead of investing more time and effort in it. This is one of main philosophies of lean development. Fail-fast refers to the ability of the system to report any failure or a condition that may lead to failure as soon as possible.
A period (generally 1 - 4 weeks long) when the agile development team produces the next increment of the software (or any other product) is called an iteration. The requirements/tasks to be done in the iteration are defined at the beginning of iteration by the product owner and agreed upon by the team. Once the iteration is ongoing, the team is not supposed to respond to any new requirement or change requests.
Kanban lets you write everything going on in the project on a board. Writing everything at one place gives you a bigger picture of things happening. It also allows you identify the bottlenecks plaguing the project. So, yes, it’s a signboard, a big to-do list for the whole project, but incredibly simple, and incredibly useful. Read more details about Kanban.
This is a consensus based approach for estimating the efforts for a task. This generally involves team members and product owners proposing estimation values using poker cards and then finally everyone agreeing to one value.
A product owner is the primary business representative who also is the voice of customer to the development team. The product owner is responsible for communicating the product vision to the team, take decisions on official releases, monitoring project progress and ROI and leading the team. Due to this wide spectrum of responsibilities, bigger projects sometimes have more than on project owners - to take care of different functional areas.
Scrum is the most widely used agile framework. It is comprised of short iterations, called sprints. It is within these sprints that the actual work is done. Scrum is comprised of 3 roles - product owner, scrum master and scrum team and 3 main artefacts - burndown chart, product backlog and sprint backlog. It also involves 4 important activities - daily standup meeting, sprint planning meeting, sprint review meeting and the retrospective meeting. With the exception of daily standup meeting (done everyday during the sprint) the other three are done once every sprint.
Sometimes the term scrum is used interchangeably with Agile, but this is not correct, Agile has a broader meaning, it involves a set of values and practices and Scrum is a specific framework that fits in under the Agile umbrella. Scrum is the most widely recognized Agile framework, and is compatible with other Agile practices.
A scrum master is one the most important role (along with product owner) in a scrum based approach. Scrum master is responsible for daily standup meetings and tracking the overall progress. It is the duty of scrum master to make sure team is not blocked at any point of time due to external or internal issues. But, scrum master should not be thought as a task master - since in a pure agile approach the team assigns tasks to itself.
Sprint is the scrum term for an iteration. As defined above, an iteration is a period when the development team works to produce the next increment of the finished product.
A stakeholder is anyone outside of the team with vested interests in the working of the team and the products they release.
Stand up / Daily Meeting
This is one of the most important activities in a scrum based approach. In a stand up meeting, the scrum team along with the scrum master sit and discuss the daily progress for a 15 - 30 minute period. Important to notice here is the need to keep these meetings short and precise. Also, the team is generally not encouraged to attend any other meeting while the sprint is underway.
A task is generally a completely broken down form of a user story. This is required since many a times, user stories are too abstract and don’t have technical information required. A task maps more precisely to the product’s features and is easier to understand technically.
A task board is the place where all the current tasks, along with their assignees are prominently displayed. Optionally task boards can also show the complete percentage or the state of the task (e.g. new, work in progress, ready to test, etc).
Over the course of time, the team encounters several deadlines, technical challenges, and even emotional challenges in their personal lives. Due to all such unaccounted for happenings, the team takes several short cuts in terms of software quality. These shortcuts while helping the product get through cause long term issues. These issues could be related to code base, the development environment, platform, libraries, design, test coverage, test automation, etc. – resulting in high defect rates, reduced velocity, poor code maintenance, and low productivity. Technical debt is a term coined by Ward Cunningham to describe the cumulative consequences of corners being cut throughout a software project’s design and development. See more here.
Agile thinking has a special focus on continuous integration and availability of a working product at all the times. In order to facilitate this test automation is an important tool. It is frequently used to automate unit tests, integration tests and functional tests. This way, as soon as the sprint is over, the finished product can be tested. Also, automation testing makes sure the commitment to not “break the build” is fulfilled.
Test-Driven development / TDD
In line with the continuous integration thinking, scrum recommends micro cycles of requirement gathering, software development, and testing. Just that the tests need to be written first (based on the feature requirements) and then the code is added. The tests are then supposed to pass and added to the automated testing environment.
User Story & User Story Points
Velocity is a measure of how much the team can complete in an iteration. It is generally measured in terms of number of user story points completed in a sprint.
Wiki refers to an editable intranet based website where the know how of the product is maintained. This generally evolves over time as the product evolves.