We have compiled a list of frequent agile questions and answers, to help you with your agile transformation.
As agile principles and practices have evolved over the past two decades, undoubtedly terms have merged, often losing purpose or clarity. So, we thought we should help by using our experience and expert agile knowledge, to bring some clarity to the agile terms being used every day. Please get in touch if you can’t find your frequent agile question listed below, or if you need a more detailed answer. We are always here to help.
Our team is made of up of agile practitioners, with decades of experience between them. Whilst we bring clarity to the agile terms being used and we’re able to answer any questions about agile practices and principles, we also bring pragmatism to any agile adoption or agile transformation.
What is the difference between a vision, mission and strategy? Collectively, the vision, mission and strategy align people around a clear ambition, purpose and approach – they paint the picture of a better future, and how the organisation will achieve it. They are also terms that get used widely and interchangeably, and as a result, can cause confusion. Let’s explore the important differences between them.
Product management is concerned with creating and sustaining products. It covers a wide range of:
Facilitating a group of people towards a shared outcome is a valuable skill in any team. For a few years, Scrum Masters, facilitators, consultants and others have gradually been discovering an amazing resource that can help.
As marketing teams move to adopt agile frameworks such as Scrum and Kanban practices, what can help is the use of user stories as tokens or tickets that remind marketeers of the work to be done.
Evidence based management is a framework developed by Scrum.org designed to enable technology leaders to develop a management approach based measuring value and evaluating the effect of change on that value. The framework seeks to emulate the tremendously successful approach that transformed medical science, a field that once relied on anecdotal evidence, superstition, hunches, and tradition. Evidence based medicine is a mature, scientific approach to decision-making in a messy, contradictory, complex field, and provided a framework to make balanced judgements on the efficacy of treatments and therapies.
Immersive Learning Dojo /ˈdōˌjō/: An immersive environment where agile teams embark on an intensive learning journey that enables teams to make breakthroughs more rapidly and consistently.
There is nothing in the Scrum Guide that says roles cannot be combined. This is true for core roles such as Product Owner and developer, and also for complimentary roles. A Scrum Master would not be breaking any rules if they also served as a technical architect; project manager; coffee shop assistant; finance director; or line manager for members of the team.
Scrum teams plan continuously across multiple horizons. In the daily scrum, the development team plans their daily activities and re-assess their ability to deliver the sprint goal. At the start of every sprint, the team needs to create a sprint backlog, giving them focus for the few weeks. Scrum teams also need long term plans that help them understand when they are likely to meet business objectives or milestones; this is release planning.
Despite the early popularity of extreme programming (XP) over recent years, it has waned. However, many of the practices within extreme programming are still relevant in modern software engineering. The scrum framework is now the most widely used and popular approach to Agile software development globally. Yet, it describes no technical practises beyond the need for a done increment every sprint as agreed in the definition of done.
The sprint review is a critical event in the scrum framework for implementing the empirical process, making the increment transparent, collaborating with stakeholders and using feedback to guide future sprints. It enables the scrum team to ensure they deliver the highest possible value.
Story points are a common means of estimating work while using agile frameworks such as Scrum and eXtreme Programming.
When you have to prioritise a list of requirements from different stakeholders or customers, you can choose from many different methods. One popular method, advocated by lean-agile approaches such as SAFe®, is weighted shortest job first (WSJF).
WSJF is an approach that gives preference to items that provide the most economic impact in the shortest duration.
When you want to express a requirement for functionality in SAFe, you can use stories, features, capabilities and epics. When is each of these used? What level of detail do they contain? And who has content authority for them?
Gathering metrics for your agile team will help them find opportunities for improvement in both the product and themselves.
In the Scaled Agile Framework® (SAFe®), there are regular events (meetings) at different levels. What are they, who should attend, and what is their purpose?
DSDM Atern is a vendor-independent implementation of the agile project delivery framework Dynamic Systems Development Method (DSDM). It is a generic approach to agile project management rather than solely focused on software delivery.
DevOps is an approach to enable teams to independently build, test and deploy solutions quickly, safely reliably and securely to customers.
An agile culture is one that has a bias towards collaboration and cooperation and minimises autocracy, control and bureaucracy. It pushes decision making down the organisation to enable teams to take ownership of business outcomes and holds them to account.
The Release Train Engineer (RTE) is a role in the Scaled Agile Framework® (SAFe). They are responsible for ensuring that the agile release train (the team of agile teams) work well together and follow the SAFe processes.
eXtreme Programming (XP) was one of the most wildly known and used agile methodologies back in the early 2000s. XP was the brainchild of Kent Beck, Ron Jeffries and Ward Cunningham, based on their collective experiences at Daimler Chrysler. Its name became marmite and put off management. It incorrectly evoked visions of surfer dudes and lack of professionalism.
A Live Virtual Classroom is a platform for delivering a trainer-led, interactive course in an online environment. They are designed to replicate the experience and benefit of attending a face-to-face training course, with the same discussion, group breakout work, questions and answers, and access to a responsive, knowledgeable expert.
In the Scaled Agile Framework®, SAFe®, Programme Increment (PI) planning is an essential element and is generally run as ‘big room planning’ event where everyone is in the same location. Often there are some people who connect remotely but how could PI Planning be done when everyone is working remotely?
You will often hear agile teams described as cross-functional or at least aspiring to be. When a team is defending why they haven’t completed something at the end of a sprint and cries “the development is done, we have passed it over to the testers!”, or “it’s just waiting for dev ops to deploy it to production”…someone will often respond with “I thought you were supposed to be a cross-functional team?”.
So, what is a cross-functional team and how would having a truly cross-functional team help address the situation above?
Empirical process control is a technique used when the complexity of activities means a defined process control cannot be employed.
We are all stakeholders at one time or another. Being a stakeholder isn’t a job description, it is just a capacity in which we operate when needed.
The Scrum framework does not prescribe how to plan a release but many scrum teams will have a ‘release plan’ that they use to track progress towards a release of software.
A release plan is a complementary practice to Scrum that looks forward over several sprints and provides a forecast of when a coherent set of functions will be made available.
Virtual agile coaching is used for distributed teams of people, to help them work together more effectively. In principle, it is the same as traditional forms of agile coaching, as it focuses on people, their interactions and the practices they use to be better at what they do.
The Scaled Agile Framework®, or SAFe®, is one of a growing number of frameworks that seek to address the problem of coordinating the activities of multiple teams when using lean and agile delivery methods. This article gives advice on how to start using SAFe.
The Scaled Agile Framework® (SAFe®) has different configurations. Many aspects are optional or depend on the configuration that you have chosen to use. However, there are 10 elements of SAFe that are considered so important to the framework that, if they are not used, then SAFe is not being used. These 10 essential SAFe elements are:
In the Scaled Agile Framework® SAFe® an agile release train (ART) is a team of agile teams. Additionally, it includes an associated group of stakeholders. An ART frequently delivers valuable functionality into a system.
The Scaled Agile Framework®, or SAFe®, has a set of certified training courses that are aimed at specific roles within SAFe. Each of these courses prepares delegates for their role in an organisation and enables the delegate to take examinations to gain the associated qualification.
The Scaled Agile Framework®, or SAFe®, has roles that are usually associated with different levels: Team, Programme, Solution and Portfolio.
The Scaled Agile Framework®, or SAFe®, is a set of workflows and patterns to help enterprises scale lean and agile practices. It is one of a growing number of frameworks that seek to address the problem of coordinating the activities of multiple teams when using lean and agile delivery methods.
In Scrum, the product owner is accountable for managing stakeholders and customers. As with any of their accountabilities, it is up to them if they wish to delegate part of their area of responsibility to someone else; ultimately, they remain accountable.
To build and deliver great products that satisfy customer needs, it is essential that the product owner deeply understands the customer. Product owners should be fully engaged in gathering ideas and feedback from them.
Most agile practitioners will be familiar with a definition of done and appreciate its value in helping teams remain transparent in how they get work completed. A similar but less commonly used concept is that of a definition of ready. A definition of ready is used to determine whether work is ready to be started in the first place – is a user story or product backlog item ready to be accepted into a sprint.
Two common stances for a scrum master are coaching and mentoring. Often these words are used interchangeably, but they are two very distinct approaches to working with and developing others.
There are only two ways to deliver more value! Either the development team deliver faster or increase the value of the work they are doing.
No matter how fast a development team becomes, if the product owner feeds them worthless requirements, then the output value of the scrum team is zero.
Facilitator is a stance that a scrum master takes as a service to their team, so that the scrum team can work more effectively, collaborate and achieve synergy. With a facilitator hat on, the scrum master acts as a neutral party who doesn’t take sides or advocate their own agenda.
When Takeuchi and Nonaka studied world leading innovative product teams in the eighties and published their paper “The new new product development game” one of the key attributes they identified was self-organising teams.
They proposed that a group possesses a self-organizing capability when it exhibits three conditions: autonomy, self- transcendence, and cross-fertilization.
Technical debt is a metaphor that leans on the idea of financial debt. As financial debt increases, the ability to repay the debt is reduced. Once the debt exceeds the ability to repay, bankruptcy occurs. So, how do scrum teams manage technical debt?
What is Agile? Agile is an umbrella term for light-weight frameworks, tools and techniques that help teams and organisations achieve agility. Initially specifically aimed at Software development, following recognition by Harvard Business Review, McKinsey & Company etc. agile is now spreading rapidly to all parts and all types of organisations.
‘Agility’ is our ability to respond to change.
We know that companies, teams and individuals who cannot respond to the changes around them struggle to compete, perform and succeed. If you can think of an organisation that has gone out of business, lost significant market share or begun to lack credibility in the eyes of its customers, then you are probably seeing the effects of a lack of agility.
Scrum is a framework that is designed for delivering software products. It comprises three roles, three artefacts and five events:
Agility is the ability to respond to change. Organisations, teams and individuals that have an ability to respond to changing consumer demand, market conditions and new technology entrants are hugely successful.
Considered to be one of the agile frameworks, alongside Scrum, XP, DSDM amongst others, Kanban has been gaining popularity as a lightweight method for helping teams deliver effectively.
Kanban is best described as “a method for optimising the flow of valuable work”, as it is not guided by rules, but key principles:
Both Scrum and Kanban are popular agile frameworks used to help teams work together to get things done. They have some subtle differences, which we have summarised below:
Business agility is the inherent ability of an organisation to respond to change.
Can you think of a business that has gone bust? Woolworths, Toys ‘R’ Us, Poundland? There are loads of them out there. These days it’s not just making a profit, but also survivability that matters.
People cite all kinds of reasons for a business failing. Strong competition, the economy and even the weather, amongst many other things.
Much is written about OKRs and their use. In this FAQ find out more about what OKRs are, how they are used and implemented and why OKRs can be useful in supporting business agility.
As agile has developed over the last 10-15 years, questions have arisen around how you scale when you get a number of teams working on the same product. There are several scaling agile frameworks designed to help to solve the problem of numerous teams working across the same or closely linked products. Using our own experience and a number of different source materials we have collated a list of the top four scaling agile frameworks, based on market share; including their strengths and weaknesses and the agile frameworks they are suited to.
The scrum framework defines three roles and gives clear accountabilities to each, in order to simplify decision-making and ensure that things get done. The primary accountability of the scrum master is to provide delivery leadership, experience and expertise by managing the scrum process, improving their organisation’s ability to deliver a valuable, relevant product.
A product owner is a decision maker.
Fundamentally, the role exists to help represent the needs of both the business stakeholders and the users within a complex environment. They broker the needs of those two sets of people condensing their requests for features and enhancements in to a single prioritised list of tasks for the development team to turn in to working product.
A development team is a group of people that work together to create software. This is complex, creative work that requires adaptability as technical challenges arise and business requirements evolve. An agile development team will seek to meet these challenges by applying the principles of cross-functionality and self-organisation.
Many teams that implement an agile framework for software delivery find it useful to have a Business Analyst (BA) as part of the team. However, finding a good definition of what a BA does in the agile context is challenging, especially because many frameworks such as Scrum are agnostic to the specific makeup of a team. Specifically, someone with a bias towards BA skills in the scrum context would typically be a member of the development team.
Think about your favourite sports team – or person. They will have a coach. In fact, many successful business people and politicians do too. Coaching is a profession that is more complex than it looks, but provides huge value when done well.
Agile architecture is largely defined by a subset of the 12 agile principles and hence this heavily influences the remit of a software architect:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
What is a stakeholder? If you are a stakeholder in something, you have an interest or concern in that thing and its continued success. In Scrum, stakeholders are not considered part of the Scrum team but are vital to the success of the team and the product they produce.
A team will always be better off with a dedicated, full time scrum master. A scrum master’s role is not about managing the Team. However, don’t fall into the trap of thinking that a scrum master is just about facilitating ceremonies. New teams in particular need a lot of training, mentoring and coaching to get to grips with the art of Scrum. This is without a doubt a full-time job.
Servant leadership is the idea that the main goal of someone in a leadership position is to serve others. A true servant leader will put other people’s needs and priorities first, and help people develop and perform as highly as possible. When reading and learning about the Scrum framework you will most often see servant leadership associated with the role of the Scrum Master.
The definition of a practitioner is “a person actively engaged in an art, discipline, or profession” or “someone who works in a job that involves long training and high levels of skill”. An agile practitioner is therefore someone actively engaged in practicing agile techniques to help organisations respond to both continued and rapid change; using their high levels of experience and skill in agile approaches to foster an agile mindset within that organisation.
The Scrum framework describes three accountabilities; product owner, scrum master and developers – but who attends what event in scrum? Detailed below are the four events: sprint planning, daily scrum, sprint review and retrospective.
User stories are not part of any particular agile framework but are a complementary practice adopted by many agile teams as a format for expressing product requirements. Due to their simplicity and versatility, user stories have become the most popular form of product backlog item.
The Scrum Guide lists the first responsibility of a product owner in managing the backlog as “Clearly expressing Product Backlog items” but what is a backlog item?
You will often hear agile teams talking about breaking product backlog items (PBI’s) down into tasks (or “sub-tasks”) but what is a task and what is the difference between a task and a product backlog item?
The Scrum framework prescribes five events; the sprint, sprint planning, daily scrum, sprint review and sprint retrospective, all of which are formal opportunities for the team to inspect and adapt something. There is however another regular, complementary practice, most Scrum teams undertake; product backlog refinement.
Behaviour Driven Development (BDD) is way of writing acceptance criteria by giving examples of how software should behave in different scenarios. They are written in a standard format that promotes clarity, as well as allowing easy integration with automated testing.
Several volumes can be written about the kind of problems implementing Scrum.
The best approach when encountering any one of the myriad of problems, is to inspect and adapt in the spirit of continuous improvement. Once the Team, Product Owner and Scrum Master want to be better and improve the ways they work, half the battle of implementation is won.
Scrum is based on a set of fundamental values. The values provide a code of behaviour, or ethics, for Scrum Teams – some rules of conduct for teams to embody and live by as they work with Scrum.
Eliminating waste is a key concept in lean process thinking. Waste reduction is often seen as a way of increasing productivity. Since lean is the grandfather of agile we can perhaps borrow this key concept and apply it to software engineering.
Through identification and elimination of waste in our software teams we can build our products efficiently, potentially reducing costs but also improving time to market.
A sprint goal is a shared high-level objective that describes the key outcome for each sprint that a Scrum team undertakes. In the same way that a product vision guides the longer-term direction of a product, the sprint goal guides the development team on why it is building the current increment. It also covers why it is worthwhile undertaking the sprint, and what value it will deliver to the product owner.
Incremental Incremental development is a development approach that slices the product into fully working slices that are called increments.
Iterative development is when teams gradually build up the features and functions but don’t wait until each of these is complete before releasing.
The daily scrum is an event that is defined in the Scrum Guide and is a specific Scrum practice.
The daily scrum is a meeting for the development team to create a plan for the day. It is not a status update for stakeholders! The product owner has no role in the daily scrum and the scrum master’s accountability is to ensure it happens, only the development team speak and the time-box is respected.
The Scrum Guide defines the definition of done as follows:
“When a product backlog item or an increment is described as ‘done’, everyone must understand what ‘done’ means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of ‘done’ for the Scrum Team and is used to assess when work is complete on the product increment.”
Here we explain the difference between UX and UI – a common confusion amongst IT professionals.
User Experience (UX) Design is the process of enhancing customer satisfaction and loyalty by improving the usability, ease of use, and pleasure provided between the entirety of a user’s interaction with a businesses, services and products.
To understand what a product led company is, we first need to understand what the difference between product development and a project is.
The sprint review is a Scrum event that takes place at the end of the sprint, just before the retrospective. The purpose of the review is to evaluate the latest features and to consider the plan for the product in the future.
Sprint planning is a Scrum event that takes place right at the beginning of each sprint. The whole Scrum team attends, and the objective is to determine the following:
Sprint retrospectives allow empowered teams to identify meaningful improvements to the way they carry out their work. They are a core part of the Scrum framework, occurring at the end of each sprint, and are a common element in Kanban and other agile approaches.
We are often asked if you need to pass all 3 assessments, (PSM I, PSM II and PSMIII) to obtain the certification as a Scrum Master. Well, most recruitment firms recognise just the PSM I to represent certification as a Scrum Master and most people who attend the PSM training course will just take the level 1 assessment.
Students of Scrum.org courses may be eligible to apply for 14 PDUs after attending a two-day Professional Scrum Foundations (PSF), Professional Scrum Master (PSM), Professional Scrum Product Owner (PSPO), or Scaled Professional Scrum (SPS) course and 21 PDUs after attending a three-day Professional Scrum Developer (PSD) course. Scrum.org do not specify which categories are covered by their training courses. It is the responsibility of the individual to decide how the PDUs are assigned across the different areas of the PMI Talent Triangle™. Please go to the Scrum.org PDU webpage for more information and guidance.
All students taking APS, PSM or PSPO courses accredited by Scrum.org are entitled to one free attempt at the relevant assessment. Scrum.org grant A 2nd free attempt if the first unsuccessful attempt is within two weeks of the course. The email you received from scrum.org lists the exact time that this deal expires. It is usually 23:59 UTC, 14 days after you receive the password email from Scrum.org.
A daily stand-up meeting is a short, time-boxed team status check, held every day, usually at a set time. The Scrum framework calls the daily stand-up a ‘Daily Scrum’.
The inspect and adapt nature of agile ways of working operates at a number of levels, from unit testing code which is done multiple times a day to reviews and retrospectives which can be held as rarely as every month. Communication is at the heart of building good teams, so getting a team to synchronise daily is a good idea – if done well.
A product roadmap is a visible plan for the future.
There’s no one type of plan. There are different sorts that will be of interest and use to different people.
If you’re using the agile product delivery framework, Scrum, the sprint backlog is a plan for the immediate sprint. Most teams will have a product backlog, which is a prioritised wish-list of ideas that need to be taken on a journey from concept to reality.
A sprint backlog is a number of product backlog Items (PBIs) that have been committed to a sprint.
A product backlog is a list of potential work items, prioritised by relative order of value. The agile product delivery framework Scrum uses time boxes to pursue its goal of incremental delivery, so for every sprint the most valuable items on the product backlog that can fit into the prescribed time box should be ring fenced – and these become the sprint backlog. The sprint backlog is then just a sub-set of the product backlog.
A product backlog is a list of potential work items, prioritised by relative order of value.
In the Scrum framework for agile product development, the sprint is a fixed period of time in which a defined set of activities take place and at the end of which a product increment is created.
A sprint would usually be set between one and four weeks and would be fixed for a product development until such time that the scrum team inspects their ways of working, during a retrospective, and may decide that an alternative sprint length may be beneficial to the way they work.
In the context of agile software product development, using a framework such as Scrum, a software product increment is what gets produced at the end of a development period or timebox.
In Scrum, for example, the regular development cycle is a Sprint, a period of between one and four weeks in which a planned set of product features are developed. At the end of the Sprint, the development team would have created new software that gets built into the product in such a way that it could be released into live operation, if that is the desire. This is the product increment.