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.

Splitting

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.

Velocity

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.

Outcomes

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…

How disruptive to an existing company culture is the Agile Framework?

I am asked this a lot, most often by Program & Project Managers who are wary of persuading Stakeholders to allow it’s adoption

The short answer is that company culture is mostly about what a company is doing and why (e.g. developing FinTech enabling better and faster portfolio rebalancing for clients worldwide), and the Agile Mind-set is mostly about how a company achieves this.

A company with vision and great teams can deliver anything anyhow. Even, dare I say, using a traditional Waterfall method.

If Agile delivers anything, it delivers a framework, top-to-bottom transparency and a cadence to the way Stakeholders prioritised outcomes are delivered.

Got a Question? Ask Agile Unpacked…

How Can the Agile Framework Help a Start-up?

There are three key ways adopting an Agile Framework can help a Start-up whether IT based or not

As we’ve mentioned in previous posts, Agile is not just for IT departments or IT-based start-ups. Adopting an Agile Framework from the get-go can significantly help a start-up in these three ways…

Agile delivers clarity top to bottom

An issue in any start-up is being able to track all the tasks, projects and must-do-now’s.

An Agile framework (and associated tools) will enable you to answer questions such as:

What are we working on right now?

What’s next?

How can we articulate progress to our Stakeholders?

Agile delivers transparency of what you’re doing and why

Agile Mind-Set aside (that’s a number of posts which we won’t go into here) adopting an Agile Framework will enable everyone in your start-up to see what the Management Teams vision is, how that breaks down into headline outcomes (Epics) which enables individual team members to be clear on what they should be doing THIS WEEK to move the start-up forward.

Agile makes it easier to track progress and make objective decisions about prioritisation

The Agile approach enables a start-up to clearly articulate what outcomes have been identified, how success has been defined, how those outcomes have been broken down into User Stories, what has been prioritised and when, and how fast the Agile team members have been tackling the work.

Got a Question? Ask Agile Unpacked…

Agile for Management Teams

What is an Agile iteration when it comes to Project and Program Management and how can it improve the quality and timeliness of delivery?

When IT teams use the Agile method to deliver software, the bi-weekly Sprint provides the cadence and framework required, along with the other usual processes and meetings such as the Scrum and Retrospective.

For Management teams it can be a little more difficult to see how an Agile framework can operate, but operate it can.

The main benefits delivered by an Agile framework for Management teams are transparency, prioritisation and robustness.

Transparency in Agile Management

Project plans existing in documents or in emails is of limited use even if one individual is responsible for the “golden copy”.

Using tools such as JIRA and Confluence, Management teams are able to contribute collectively to the definition and decomposition of high-level outcome definitions.

These “Epics” are available for Program and Project Managers to see and for Product Owners to review, seek elaboration and to decompose into User Stories.

Prioritisation in Agile Management

A key benefit of having Management Teams’ required outcomes in tools delivering transparency is the ability to make prioritisation an ongoing “delivery” of the Management team. Prioritisation’s never stay the same for long and it is fatal for any project to pretend they do.

Robustness in Agile Management

With transparency and the ability to deliver ongoing prioritisation’s, the Management Team can deliver robustness in direction which in turn drives resourcing. If you know what you’re doing, why and in what order, you can massively improve the robustness of your projects and so decrease risk.

Got a Question? Ask Agile Unpacked…

Do Agile Teams Really Self-Manage?

At the End of a Sprint

Along with a Retrospective, the end of a Sprint should result in a useful & readable update for Stakeholders

It is not enough to close a Sprint, have your Retrospective, roll any incomplete User Stories, close the Sprint in JIRA and open the next.

Stakeholders need to be updated in a clear, consistent and useful way on the outcome of each Sprint.

High Level Sprint Summary

Before any detail is articulated it is useful to summarise a Sprint in an easy-to-consume fashion. I have found that a simple table is of most use which can ideally be standardised across Agile teams.

This may include Velocity and/or Burn Up (more on that on another post), as well as Average User Story size, percent complete (for User Stories and Acceptance Criteria) and percentage of User Stories rolled to the next Sprint with any headline reasons.

Product Progress

At a high level it is useful for Stakeholders to know which products (whether technical or business relates) have been furthered by the Sprint and which have not.

Epic Progress

As products can straddle more than one Epic, it is useful also to report back to Stakeholders what progress has been made tracing back to a User Story’s Epic. This will help Stakeholders understand how accurate their sizing has been.

User Story Progress

This may include completed User Stories and their contribution to the development of products. At a more granular level some Stakeholders may want to see the progress of each User Story which has been rolled into the next Sprint. For example a User story may have been sized at 5 days and four days have been completed vs. the Acceptance Criteria. There’s a big difference between saying User Story 123 has rolled, and User Story 123 has been rolled at 80% because of an external dependency.

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…

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.