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.
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.
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?
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.
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.
One of the strengths of an Agile framework is that it allows for change during the flight of a project and it is a rare project which is planned in advance and then executed without experience some kind of change in priority or as a result of external events.
Implementing an Agile framework for management and stakeholders sharpens everyones engagement with what is being done now and what comes next and why.
Unnervingly, it also delivers a high degree of transparency to stakeholder prioritisation’s and estimations which of course some do not enjoy.
This article is being written in May 2020 as COVID19 appears to be on the decline, looking at globally reported death stats.
With many people being furloughed or let go it is a perfect time for organisations large and small to re-think how they can best grow again in such a way to make being resilient a part of their DNA.
Agile is not a panacea but it can contribute massively to developing resilience all the way from the Board through to Senior Management, Stakeholders and to individual Agile team members.
How can it do this? By focusing less on each individuals job title and location in a hierarchy and focusing more on broad skill sets (the elusive T-shape), creativity and the willingness and ability for members of an organisation at all levels to contribute to the Agile Mind-Set which in turn delivers Outcomes.
A true Agile Environment allows an organisation to easily change direction (I didn’t want to say “pivot” here, but here it is), whether that change is minor (e.g. reducing 50 features to 10 and doing them differently) to major (e.g. changing the actual nature of the products and services an organisation delivers).
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.
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.
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.
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.
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.