When a team forms at the beginning, after going through the Discovery Phase, they often fall into the trap of going straight into sprint without a clear plan for execution. This is one of the great agile, and particularly scrum pitfalls. The team can then spend many sprints and therefore months, spinning aimlessly without getting results. Therefore the phase of Inception is vital to get the team to build a plan for delivery. Below is one of my experiences of doing the Inception activities with a team in the Banking industry - I've highlighted some of the key activities only.
A. Inception: knowing what to build and where you should start
We started with Inception, a pre-execution exercise, that served to set the scene for the project and led to the team developing an adaptive plan.
As the project's goals are clearly spelled out by the Regulator, the team did not need to spend time reviewing or reframing the goals. However, as the Regulator has provided the Bank with a detailed set of new requirements, it was important to review the requirements, check for shared understanding and alignment with existing project activities.
The core team (developers, architecture, business analysts, change manager, project managers, test managers, data analysts, business cluster stakeholders, etc.) and key stakeholders participated in productive discussions. The knowledge transfer and knowledge sharing that are characteristic of a cross-functional team coming together around a shared goal and vision, were quite evident in the Agile sessions. Next comes story mapping.
B. User stories or user journeys
Prior to the planning sessions, the project team prepared the user stories, based on the reporting categories and requirements determined by the Regulator.
Time could then be spent during the sessions understanding each user story and unpacking the detail of the activities, technical components, and processes required to fulfill each one, including any known risks, dependencies and acceptance criteria.
C. Estimation
The most challenging, yet most illuminating, exercise was the estimation step where each user story was sized in terms of complexity of effort, relative to another user story.
For this exercise, called the “Agile planning game”, the team used the Fibonacci number sequencing technique to estimate each user story. (The Fibonacci numbers are 1–2–3–5–8–13–etc.)
Every team member was involved in clarifying questions and debating the effort of producing the work. Each member then held up a card showing their individual, estimated Fibonacci number. Robust discussions ensued until consensus was reached on one estimate, and each estimate was considered relative to other user story estimates.
D. Prioritisation and sequencing
Once the ‘features’ of each user story were identified and analysed, and estimates agreed, the team went through a prioritisation exercise, where the merits of each feature were discussed. Instead of asking the question, “Is this feature important?”, the Coach asked: “Which one of these two is the priority?” and helped the team organise and visualise the features.
Generally, a MoSCoW prioritisation technique is used at this stage; however, the team decided to forego the exercise as all user stories are ‘must-haves’ required for compliance to the Regulator.
The in-depth discussion that this exercise generated, led to a clearer, unambiguous understanding of each feature and its importance/priority.
Asad Patel, is currently an Agile Coach and is passionate about adopting and changing the mindset of people, teams and organisation to become more focused on creating happier people. SimplyAgile specializes in Inception Planning and Release Planning - please refer to our Services for more info.
Comments