Epics, Features and Sprints – Oh My! The prioritisation process at the Department of Human Services
The nomenclature around SAFe® and other agile processes can look complicated and seem overwhelming. However, the SAFe® process followed at the Department of Human Services’ Business Transformation Branch is nothing short of a well-oiled machine using rigorous agile procedures.
Every 12 weeks, the Business Transformation Branch follows the below procedure to collate, analyse, advocate, prioritise, build and release features (i.e. improvements) that make claims processes easier for their staff and for their customers.
This impressive process ensures that all stakeholders are engaged, work is prioritised appropriately, and features are built and achieved within agreed time frames. Effective and efficient, this process has delivered tremendous results for DHS’s client community.
The process is as follows:
- Features are identified and placed into a new or pre-existing Epic (a larger work objective or piece of work)
- Features are placed on A3 page
- Teams gather to discuss each feature (and questions are asked – How much effort is it? What would the design potentially be? What are the business issues? Who are the stakeholders we need to engage in order to deliver this?)
- Brainstorm is conducted
- External workshop is hosted with stakeholders (builds a case as to what is worked on in the upcoming sprint and why)
- “Feature Fair” conducted with a variety of staff to gain additional insights and perspectives – like a roadshow
- Cost of Delay process undertaken (go through a voting process, where a range of senior executives representing different areas of the business get to vote on each feature with a deck of cards they are given. They will weight each feature through lenses: the business value, the time criticality (how crucial it is for this feature to be completed quickly), the opportunity enablement, and the risk reduction.)
- List of features are prioritised based on Cost of Delay
- Final review or “sensible trousers” – is this what we expected? Are there any obvious gaps or do we need to tweak the order?
- Features are allocated to teams (while they are still working on their previous/current increment feature)
- Teams then undertake their own discovery process (prior to the increment commencing)
- Program Increment Planning day is hosted (two day event)
- During the two day event, teams break their features down into two week sprints within the 12 week program increment by representing their feature as a series of stories framed from the user’s perspective.
- Throughout the day, teams continually highlight and refine the issues and risks facing their delivery. The teams escalate the items they can’t resolve themselves to the Management group.
- In the evening, a core Management group stays behind to discuss the issues and risks escalated by the teams. This group stays on into the night until the items which require an immediate response have been resolved, owned, accepted or mitigated. These outcomes are played back to the teams in the morning to enable more refined planning on Day 2.
- At the end of Day 2, the teams present their plan to the broader stakeholder group, including Management.
- Confidence vote occurs – teams present to the rest of the organisation to ‘pitch’ their feature and its development and the broader team votes on their confidence of the feature being developed to plan.
- Teams return to execute the plan – including analysis and design
- Features are built (daily stand ups, scrum master meetings and team meetings occur according to team social contracts)
- Features are tested
- Features are released and sent to BAU
Keen to see this process visually? Check out a great visual of this process here.
