Do those un-delivered User Stories at the end of a Sprint really need rolling?

It is a mistake to continually roll unfinished User Stories from Sprint to Sprint. Instead pay attention to them and consider what is going on.

When prioritised backlog items have not been completed during a Sprint it is worth taking a look at them at least to find out if they are still required, correctly annotated and have useful Acceptance Criteria.

Rolling unfinished items “automatically” can use up a significant amount of bandwidth in the next Sprint, blocking other potentially more highly prioritised items.

The first step should always be to check with the Product Owner who should be able to make the decision on whether to roll, park or seek further elaboration which may require a re-write of either the User Story of the Acceptance Criteria.


Another option for the Product Owner and team is to split a User Story into smaller pieces, although if the sizing had been done correctly up front this should not be needed, unless new information has come to light, especially if a third party is involved.


If a User Story is rolled or parked, the team will not be credited with the Story Points which can affect their Velocity. This is not necessarily a bad thing as it reflects the reality of what’s happening. Perhaps an Agile Coach is required to help the team(s) with sizing and engagement with Stakeholders to better define the Definition of Done.


The aim of any Agile Team is to deliver the outcomes required and prioritised by the Stakeholders. The wrong thing to do here is to blindly throw resources at a User Story proving difficult to close out, without escalating. It may be the case that a User Story can be cancelled if it begins to roll without a clear end in sight.

Got a Question? Ask Agile Unpacked…

Stakeholders and their Epics

Stakeholders should write, size and prioritise their Epics, but watch out for the signs it’s not working right

For Product Owners to decompose Stakeholders Epics into User Stories & Acceptance Criteria, the Stakeholders must first write their Epics, size and prioritise them.

Here are some sign to watch out for which can indicate that the Stakeholders Epic sessions are not working properly and need to be addressed…

The Epics don’t make sense

If you read an Epic and it doesn’t make sense, then A) Product Owners cannot decompose it, and B) It means the Stakeholders have too much in their heads (probably assumed) and haven’t articulated it clearly enough.

It can typically fall to the Product Owners to have an Epic clarification session with the relevant Stakeholder(s) to re-write the Epic to make it decomposable.

The Epics are really long

An Epic doesn’t have to be War and Peace (despite being called an Epic). The longer an Epic is, the more open it is to ambiguity or misinterpretation. Encourage Stakeholders to keep their Epics short and to the point.

Epics without Acceptance Criteria

If an Epic doesn’t have any Acceptance Criteria how will the Stakeholder(s) know whether or not it’s been delivered? Product Owners should encourage Stakeholders to write a number of Acceptance Criteria which collectively are the Definition of Done.

All Epics are Sized as SMALL or HUGE

It doesn’t help if Epics are either sized as small (e.g. one Sprint) or huge (e.g. 8 or more Sprints). If Epics are estimated using t-shirt sizes (XXS, XS, S, M, L, XL, XXL and OMG) then any Epic at the more obese end of the scale really needs to be decomposed by the Stakeholders into smaller sizes otherwise they risk becoming a Waterfall Project in themselves.

Stakeholders are unavailable to agree User Story decomposition

Any Stakeholder genuinely interested in how their Epic has been decomposed should be willing (if not champing at the bit) to sit with you and knock out what the User Stories are. Ideally the Product Owner should drive this session – the aim being to come out of the session having worded the User Stories and agreed them with the Stakeholder(s) in real time.

Got a Question? Ask Agile Unpacked…

Agile Health Checks are not a Score out of Ten

An Agile Health Check is best delivered with an objective approach and an empathetic lens

An Agile Health Check is not as simple as scoring User Stories and Acceptance Criteria out of ten (although those materials are definitely a part of the health check analysis).

An objective approach is the driving force of the health check – for example attending Stakeholder meetings where Epics are created, sized, prioritised and elaborated. In addition, Agile Unpacked takes an empathetic view of how the daily Scrums are working, how the Product Owner works with the Agile Team members to decompose Epics, and how they interact and challenge Stakeholders.

The outcome of the health check lists the factors we believe are key to a highly performing Agile Environment, annotated with what’s great, what’s ok, and what needs improving.

In addition we highlight the key items which need addressing to deliver the most impact which can typically be things like communication between PO’s and Stakeholders, articulation of success, and effectiveness of the daily Scrum.

Got a Question? Ask Agile Unpacked…

Giving useful feedback in Scrums

Be as clear and objective as you can during the Daily Scrum – use “SBI”…

Scrums can be rushed, stressful and a minefield of opportunity to annoy someone else in your Agile team.

Avoid phrases such as “You said …” and “You did …”

One way to avoid this stress and to contribute towards a constructive Scrum is to adopt the “SBI” way of giving feedback – Situation, Behaviour, Impact.


Describe the situation and be clear and objective about where and when it happened. For example “During this sprint twenty bugs were fixed but ten new ones have been introduced”.


Describe the behaviour your think contributed to the situation but again, be clear and objective. Don’t get personal. For example “The dev team are down two people this month.”


Describe what you think the impact has been and ideally contribute ideas which may help resolve the situation. For example “This has led to a degradation in the dev teams ability to fix bugs and deliver new functionality at the same time. One idea is to focus on bugs for the next Sprint, or reprioritise the new features.”

Agile Mind Set

As part of the Agile mind-set, keeping it real, objective and positive contributes significantly to success of individuals as well as the team and hence organisation.

Got a Question? Ask Agile Unpacked…

How will you know when you have reached your goal?

Goal setting is an essential part of an outcome-driven Agile environment – but how will you know when you have reached your goal?

An often overlooked element of goal setting is the “definition of done” – which you need to answer the question “Are we there yet?”

In Agile this translates in part to defining useful and realistic Acceptance Criteria at the Epic level as well as how that decomposes into User Stories and their Acceptance Criteria.

When defining an Epic or high-level desired outcome it is worth asking these questions which will help you facilitate the above:

What do you want?

What is your desired outcome?

If you got it, what would you have?

How will you know when you have reached your goal?

What does success for this goal look like?

GROW Your Projects Before They Start

What are your Goals, what is your Reality, what are your Options and how strong is your Will?

GROW is a very useful acronym which you can use before you embark on a new project or add a new Epic to your Stakeholders backlog. It describe the arc from knowing what you want, to knowing how to do it and whether or not you have the will.

G is for Goal Setting

What are your goals exactly? What is the desired outcome? Be specific.

EXAMPLE 1: I want to play centre for Manchester United.

EXAMPLE 2: I want an Aston Martin.

R is for Reality

What is the reality of you or your organisations situation?

EXAMPLE 1: I am 47 years old and so unlikely to play centre for Manchester United.

EXAMPLE 1: I have a car currently worth £12k and I earn £75k a year. A new Aston Martin could be out of my reach and not so popular with my wife as we’ve already decided to move house in the next year or so.

O is for Options

What are your options? Name them.

EXAMPLE 1: I could join a team suitable for my age range, or I could train to become a referee or linesman. Maybe I could join the Manchester United organisation in some way even if it’s for their junior teams.

EXAMPLE 2: I could save up and sell my car in order to buy a second hand Aston Martin. If I need a second car for the school-run perhaps I could lease a small car.

W is for Will

How strong is your will and that of your fellow stakeholders?

EXAMPLE 1: Actually, I don’t want to train three times a week to be a linesman for my local junior team which won’t guarantee I’d get into the Manchester United organisation. Perhaps my resources and will are better placed elsewhere.

EXAMPLE 2: If I save £X a month for a year then sell my current car, I’d be able to buy a second hand Aston Martin and lease a used Fiat 500. My wife is fine with this so long as it doesn’t impact our ability to buy our next house. I’m going to start this month and keep track of everything in Excel.

The Agile Glossary

A new word is like a fresh seed sewn on the ground of the discussion – Ludwig Wittgenstein

Acceptance Criteria (Given, When, Then)

The format “Given, When, Then” is a way of writing Acceptance Criteria for a User Story.

It works like this: Given (context), When (an action), Then (an outcome).


Given my car has a full tank of petrol which should last 300 miles,

When I take a journey of 100 miles,

Then I will be able to drive without the need to refill

A User Story would typically have one Acceptance Criteria but may have more depending on the complexity of the User Story. If, when writing Acceptance Criteria, it turns out to be complex – you may want to consider breaking your User Story into smaller pieces.


A framework of people, processes, actions and materials which deliver the desired outcomes.


An anti-pattern is in effect a solution to a problem, but where the solution (which may appear to be useful at the time) may actually not be very effective and worse still, cause further issues.


The backlog is list Epics, User Stories or Features which have not been prioritised in the current / upcoming Sprint. The Epic backlog is maintained by the Stakeholders which defines which User Stories or Features the Project Team should prioritise in turn.

During a Sprint an emergency may cause a User Story from the Backlog to be promoted into the current or next Sprint. Similarly, a User Story which suddenly becomes unimportant, or has a dependency on a 3rd pty and cannot be completed in the current Sprint may be demoted to the Backlog.

Backlog Refinement

Typically in a bi-weekly meeting the Backlog is reviewed, prioritised and sized in readiness for the next Sprint. Once refinement has been completed and your team are clear on the contents of the next Sprint, it should ideally be replayed to the Stakeholder(s) for approval.

Behaviour Driven Development (BDD)

Behaviour Driven Development is the method which encourages Acceptance Criteria in using the “Given, When, Then” format.

Burn-Up Chart

The Burn Up Chart shows the number of User Stories which have been delivered vs the number of User Stories. It is normal for some User Stories to be added and some to be removed from a Sprint while it’s in-flight – see the example below:

Business Agility

Business Agility is the capability of an organisation (or sub-division) to adapt quickly to internal and external changes, to respond quickly in a productive manner and to focus on continuous competitive advantage.

Business Agility encourages skills such as creativity, adaptability and resilience – which in turn help deliver the Outcomes required to remain agile.

Continuous Delivery

Continuous Delivery is one of the aims of the Agile Framework. Each two-week Sprint should deliver tangible value in the form of a completed widget (product, software, process, material etc) or in the form of having progressed the development of a Product.

Daily Meeting (aka Scrum)

See “Scrum”.

Definition of “Done”

The Acceptance Criteria attached to a User Story define when the User Story has been completed – or is “Done”.


An Epic is a large piece of work typically defined by Stakeholders or a Program Manager. For example “As ABC Ltd we have on-boarded a 3rd pty provider to satisfy our Regulatory Reporting requirements”.

An Epic usually comes with a t-shirt size ranging from XS to XXL – using the same Fibonacci series as “sizes” but typically in weeks rather than days. For example an extra-small “XS” Epic may mean one Sprint, and a medium “M” Epic may mean 4 weeks.

An Epic usually also comes with Acceptance Criteria, when help Product Owners and Project / Program Managers to break down an Epic into User Stories.

It is important than once this break-down has completed, it should be replayed to the Stakeholders / Management Team to make sure they understand and are happy with the approach.


A facilitator is someone who conducts a meeting – their focus being to create the conditions and to pursue the objectives of the meeting.

Fibonacci Sizing

Agile attempts to define a better way of sizing Epics and User Stories by limiting the choice of estimation to the Fibonacci series.

In practice this means that you can estimate the number of days (aka Story Points) to be 0.5, 1, 2, 3, 5, 8 or 13 days. Yes 0.5 is not really in the Fibonacci series but is necessary to size User Stories which will take less than a day.

If a User Story is sized at 5 or more Story Points you may want to consider breaking it into more than one story.

Incremental Delivery

Incremental Delivery means adding new functionality (e.g. in software) in as small chunks as possible – each defined by a User Story with Acceptance Criteria.

INVEST (Acronym)

INVEST in Agile is an acronym which refers to how a User Story should be written:

I = Independent of other User Stories

N = Negotiable – i.e. not a hard specification for features

V = Valuable – i.e. to the incremental development of a Product

E = Estimable – i.e. you can estimate how long it will take to complete vs. it’s Acceptance Criteria

S = Small – i.e. to ideally fit into a Sprint

T = Testable – i.e. the User Story comes with useful Acceptance Criteria


An Agile Iteration is the length of the Sprint. For example if your Sprints are two weeks in length, you might say that a Medium Epic will take four iterations to complete.


Kanban derives from a Japanese method where work and it’s breakdown and status are displayed visually on a Kanban Board.

In it’s simplest form it has three columns To Do, Doing and Done.

In practice Agile will use a few more columns – e.g. in JIRA to keep track of the status of each User Story in the daily Scrum.

Milestone Retrospective

Similar to a bi-weekly Retrospective at the end of each Sprint, a Milestone Retrospective looks back at the period since the last milestone to identify what went well and what could have gone better.

It is important that a Retrospective has specific Outcomes – for example a set of actions which are fed back into the Agile process to help make improvements or avoid making the same mistake again.

Minimum Viable Product (MVP)

An MVP derives from “Lean Startup” and means an initial version of a new product which “allows a team to collect the maximum amount of validated learning about customers with the least effort” (Eric Ries, Author of “Lean Startup”).

In practice this means your MVP should be useful and deliver against a desired Outcome with the least effort. Typically this means building in assumptions, short-cuts and hard-coding (business or technical) into your MVP.

Planning Poker

Planning Poker is an informal way during the Backlog Refinement meeting to size User Stories.

Once a User Story has been described (ideally by the Product Owner (PO) or an SME) everyone is asked to hold up cards or fingers (careful now) indicating how many Story Points should be associated with the User Story.

The PO or SME will check the results and challenge any outliers. For example if most people hold up three fingers and one holds up one finger – that person should explain why they think this User Story is one Point.

Product Owner

A Product Owner is not a Project Manager. In Agile, each team should “self-organise” which may need assistance from the PO.

The PO should push back on any additional User Stories which Stakeholders / Management Team may want to add once a Sprint is in-flight. If an emergency occurs then of course some User Stories can roll into the next Sprint to free up resourcing for the emergency.

The PO has to balance the demands and timelines of multiple Stakeholders.

The PO is responsible for each Sprint, beginning with understanding an Epic, translating into User Stories and running meetings with the exception of the daily Scrum.

Proof of Concept (PoC)

Although not strictly part of the Agile Framework, setting aside one or more Sprints to deliver a PoC is a very powerful method especially for technical projects requiring software development. PoC’s typically require a number of assumptions and hard-coded data which in turn enable the testing of a concept such as “Can we join trade data from multiple systems into one database for portfolio analysis”. In this example you may have to “fake” unique trade id’s or skip what would normally be unified static data to see if, once assembled, the joined up data works.


A Retrospective is an essential part of the bi-weekly rhythm of the Agile process. It occurs at the end of a Sprint, when the Scrum Master hosts a meeting where team members say what worked well, what didn’t, and what actions may be useful to capture to help improve the Agile process.

Typically the Scrum Master would own this process of capturing, communicating and tracking actions.


The Daily Scrum is the heartbeat of the Agile Framework. Each morning, the Agile team should assemble and each team member should review in just a few minutes where they are with each of their User Stories.

This session is also very useful for team members to highlight any problems they’re having – potentially to engage help from other team members, the PO and/or the Scrum Master.

Scrum Master

The Scrum Master acts as a facilitator for the Stakeholders, Product Owners and Agile team members.

Most importantly, they run the daily Scrums and although they might not get involved in team members issues, they will capture the issues and manage a log.

Scrum Masters assist PO’s and help to improve the overall efficiency of the team.

Scrum Masters should also help motivate and empower the PO and especially the team members.

For Stakeholders as well as the PO and team, Scrum Masters produce MI for everyone to help make the planning, backlogs and Sprint Burn-Up’s all transparent for all to see.

Scrum Masters should be able to answer enquiries from Stakeholders and Senior Execs etc regarding the state of Epics, each teams Velocity and the status of any individual Sprint.

SMART (Acronym)

SMART is an acronym used when setting goals or milestones:

S = Specific – i.e. when setting a goal you should be as specific as you can about what you want to achieve

M = Measurable – i.e. what metrics will you use to know whether or not you achieved your goal? Also known as Success Criteria. For long projects you may what to set intermediate goals which are measurable.

A = Achievable – i.e. to make sure your goal is achievable and at the same time motivating for your team. If the ultimate goal is outside of your teams skill set, an intermediate goal could be to complete some training.

R = Relevant – i.e. the goal you are setting is in context with a higher level goal or vision within your organisation.

T = Time-boxed – i.e. in addition to being relevant, your goal should be achievable in a reasonable time, which is also part of the success criteria.


A Sprint is typically the two week period when a planned, refined and sized set of User Stories is to be worked on.

Sprint Backlog

The Sprint Backlog is the set of User Stories contained in this Sprint. It is not unusual for the scope of the Sprint to change along the way. That said, it is the Product Owners job to manage & push-back on the scope-creep and involve the Scrum Master and Stakeholders in deciding which User Stories should be pushed onto the main Backlog.

Sprint Planning (aka Refinement)

Sprint planning typically occurs a day or two before a new Sprint commences. The planning session is the final stage in defining the Sprint Backlog, making sure the User Stories are well defined, sized by the team and have good Acceptance Criteria to enable a team member to work on each User Story.

Story Points

Story Points are in effect the same as Sizing – i.e. if you size a User Story to be 3 days, you can say the it has three Story Points. Note – it is not necessary to equate one point to one day. An Agile implementation can define what it means by one Story Point – for example that could equal one hour.

User Story

A User Story is the smallest chunk of work in the Agile Framework. It has Acceptance Criteria so you know when it has been completed, and it will be sized by the Agile team so you know about how long it should take to complete.

An Epic comprises many User Stories.


Velocity is the rate at which an Agile team completes it’s work (User Stories).

In effect it describes how many User Story points a team can handle in a Sprint.

This is very useful information for the Product Owner, Scrum Master and for Stakeholders as Velocity information helps to predict the work-rate of each Agile team.

In turn this makes it easier to forecast milestones and Epic completion dates.

It will typically take a number of completed Sprints before you have enough data to start articulating Velocity and using those numbers to predict work rates.

Vision Statement

Each Product should have a Vision Statement. It should be short, clear and ideally motivating for the team.

The Vision can change as Sprints develop (remember – stay flexible) – and it is important to share the Vision Statement with Stakeholders, the Scrum Master and the wider team.

If Stakeholders have defined Vision Statements at the Epic-level, it should be possible to dove-tail Product Vision Statements into those of the Epic.

A template to help drive Vision Statements is:

Target Group / Needs / Product / Value

or, if you’re developing a product to sell…

For (the target customer)

Who (statement of the need)

The (product)

Is a (type of product)

That (key benefit)

Unlike (competitor)

Our Product (further elaboration)


For people who want an easy way to rent cars, the vroomer is an app that lets users choose a car at the pick-up point and receive an electronic key. Unlike existing car rental companies our product is online, secure, flexible and FAST!

Theory of Constraints (Goldratt) – Summary for Agile

In 1984 Eliyahu Goldratt published a book called The Goal to help companies identify weak links in the pursuit of continuous improvement.

This overlaps into how the Agile works – in having the flexibility to identify what matters the most NOW in a project or program.

The Theory of Constraints is about seeking out the weakest link in a project, program or organisation and to fix it. Goldratt describes three core types of constraint:

Equipment: The way equipment is currently used limits the ability of the system to produce more salable goods/services.

People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint.

Policy: A written or unwritten policy prevents the system from making more.

Once a constraint (weak link) has been identified it should be fixed as the most important thing to do right now. Goldratt describes this as “breaking” the constraint.

To enable breaking of a constraint, agreement is the enabling factor, where stakeholders have to agree what the problem is, what the solution is and to implement a fix.

This approach is similar to prioritising an Agile Epic and to gain consensus on the Acceptance Criteria and breakdown into User Stories.

Although it may not be advisable to re-focus all your resources every time a constraint has been identified, there is value to be gained in focussing some resources to identifying and breaking constraints.

Daily Scrum Health Check

If an Agile team is sub-optimal or worse dysfunctional, it will show in the daily scrum. This is the best time and place to start conducting an Agile Health Check.

Signs of poor mind-set and engagement include lack of attendance, lateness of attendance, overly brief summaries of where an individual is in the Sprint and lack of progress – e.g. continually rolling User Stories from day to day and then into the next Sprint.

At Agile 7 we can conduct a one-day health check on your Agile implementation as well as a deep dive which includes 1:1 discussions with individual Agile Team members including Scrum Masters and Product Owners.

The difference between firing and not firing on all cylinders for an Agile team is enormous in terms of collaboration and delivery.

To health-check your Agile environment please contact Agile Unpacked – we can help you make a difference