Stakeholder / IT Engagement
The following document is a description of how SEKO stakeholders and the project management team can work with IT partners over the defined build-out period of a defined IT project.
Preliminaries / Preparation
There should be some important preliminary steps, carried out between the SEKO Product Owner and other SEKO Management and key business stakeholders:
Agree Project Constraints
In the Time vs Cost vs Scope equation, we either:
a) Fix the delivery scope and the resource profile (stakeholders, business analysts and IT development teams). From this, determine the achievable end date for delivery; or
b) Fix the resource profile and the deadline. From this, determine the scope of what is deliverable within that period; or
c) Fix the scope and the deadline. From this, determine the resources / costs required to keep to this schedule for the given scope.
Agree the Project Methodology
It is recommended that an ‘agile’ methodology is adopted, with the development effort parcelled up into two week ‘sprints’. A more detailed description is given in the ‘Agile Process’ section below.
The alternative would be the traditional approach of writing a requirements specification, hand this over to the IT Development team(s) at the start and then see the product at the end, with perhaps some interim meetings, updates, and demos. However, as part of the new SEKO Roadmap strategy, the desire has been expressed to adopt a more agile approach to software development with continuous stakeholder engagement throughout the build phase.
Capture System Features into a Requirements Catalogue
The high-level requirements of the desired system delivery should be captured in a bullet pointed list to a degree of detail which gives a clear overall description of the ultimate functionality, with each item in the list a separate required ‘feature’ of the system (it is helpful to think of each feature as a bullet point about the system that could be listed in a detailed sales brochure or presentation).
This list should be stored in a common shared repository called the Requirements Catalogue, that all stakeholders and IT teams can access, as it could be subject to ongoing change and change management.
Agree the high-level Project Roadmap
The set of high-level features from the Requirements Catalogue must be put into a prioritised order and allocated to main delivery phases, to create a high delivery roadmap, with particular focus on the next main delivery phase.
Where features are too large or high-level, they may need to be first broken down to a more granular level in the Requirements Catalogue, to allow splitting across different main phases.
This step must be carried out between the SEKO Product Owner, the main IT Architectural Lead, and Business Analysts, with review & approval of SEKO Management and key SEKO business stakeholders.
The IT involvement is essential because, in addition to the main business priorities, there will be important technical foundations and approaches that must be in place in earlier phases to avoid costly re-work later.
Plan the Project focussing on the next Phase
Having agreed a high-level Project Roadmap, a detailed project plan for the next main phase must now be produced, given the known resource profiles of the teams and a knowledge of the Agile Process (see below). This must be carried out by the SEKO Product Owner in conjunction with the IT Development Team managers and SEKO business stakeholders.
Agile Process / Methodology
The Agile method breaks down the main build phase into a series of two-week ‘Sprints’. During each sprint, the IT development teams work on an agreed set of ‘User Stories’. This means there needs to be a continuous flow of user stories prioritised and prepared with enough requirements detail in advance of each sprint, within a centrally visible ‘Backlog’ (typically using JIRA as the management tool).
Create the Backlog of User Stories
Guided by the Project Roadmap, the prioritised Features to be included in the next main delivery phase are further broken down into a first pass set of User Stories and loaded into the backlog.
Each User Story must represent a self-contained item of functionality and development effort that a single developer can work on within a two-week sprint, and that can ideally be visually demonstrated to stakeholders during a sprint demo.
Note that user stories may need to be broken down into smaller units if they would be too large or complicated to fit within a single sprint.
User stories should also be traced back to their originating Feature. These Features can themselves be included in the backlog as ‘Epics’ in JIRA and so multiple user stories are associated with each Epic (although only the user stories are addressed in the sprints).
This task should be carried out by the Business Analyst(s) with help from SEKO business stakeholders, plus the IT Development leads for the more technical items.
Prioritise the Backlog
The user stories should be arranged in priority order, guided by the Project Roadmap. This needs to be carried out by the SEKO Product Owner, IT Development Team Lead, key SEKO business stakeholders, and Business Analysts.
Again, technical/IT input is essential to ensure correct priority is given to architecturally significant or technically foundational user stories, and to ensure stories are at the correct level of size granularity for development sprint planning.
A key output from this phase is to identify a set of high priority user stories that the development teams can immediately start estimating and sprint planning for (see below). These must be items where the business or technical requirements are already well elaborated and have high business or technical priority.
It is likely that this first set of user stories will lean more towards technical foundations rather than fully demonstrable business deliverables.
Estimation and Sprint Planning
Define a sprint goal - each sprint should deliver a meaningful and demonstrable improvement to the system.
In the week prior to the start of each new development sprint, the IT Development Team Lead has a meeting with their developers to go through the user stories that are ready for sprint planning (i.e., the high-priority output of (2) above and the output of further processes from the cycle described below).
During this meeting they will ‘story point’ each of these ready user stories with a metric describing the amount of effort required to code and internally QA/test each of them. This can be done using various point-scoring techniques, holding up number cards, ‘planning poker’ etc.
They will then determine how many of these user stories can be included within their next two-week development sprint, based on their team profile, holidays, absences etc. Over time they will gain experience about how many ‘story points’ in total can be delivered during a sprint for a given number of developers and QA staff (see also ‘sprint retrospectives’ below).
Once the user stories that can be tackled in the next sprint have been determined, these items are moved into the next sprint bucket label. Those that could not fit are moved to the top of the backlog (and therefore remain top priority to be swept into the following sprint). JIRA is an excellent tool for managing all this process.
Refining the Backlog
The following describes the backlog refinement process (this is also known as ‘grooming the backlog’), which should be done on a weekly basis between the SEKO Product Owner, the IT Development Team Lead, Business Analysts, and key SEKO business stakeholders.
On a weekly basis, the backlog must be reviewed for the user stories that have not yet been marked as ‘ready for sprint planning’. These are mostly stories with not enough detailed requirements against them yet.
This process ensures that:
a) User stories that have not been marked as ‘ready for sprint planning’ thus far, but have now been elaborated as per 5 below, are now properly marked as ‘ready for sprint planning’.
b) Any new user stories are captured and added in, as more technical and business requirements come to light.
c) All backlog stories remain correctly prioritised (note, priorities may have shifted, and new things may have come up).
d) The higher-priority user stories that are potential candidates for the next-but-one sprint (the one following the next planned sprint, see 3 above) are identified.
e) This subset is refined to make sure they are consistent and expressed correctly and at the correct level of size granularity.
f) Of these user stories, the ones that require further requirements elaboration are identified (e.g., more detailed description of what needs to be delivered, with supporting logic / rules / screen mock-ups, flow diagrams, test outcomes etc).
Requirements Elaboration
The user stories identified from 4(f) above must be assigned to Business Analysts who must then capture the detailed requirements logic for these items within the time between backlog refinement and the next-but-one sprint (2-2.5 weeks).
The detailed requirements (more information, screen mock-ups etc) must then be included & attached in those items in JIRA by the Business Analysts (after verifying with the business and gaining some technical feedback as needed).
These items will then be marked as ‘ready for sprint planning’ in the weekly Backlog Refinement meeting in 4(a) above and will then go through the estimation and sprint planning process by the Development Team(s) the week before the next-but-one sprint, as described in 3 above.
During Each Sprint
During a two-week sprint, IT development teams may have a daily ‘stand-up’ meeting (otherwise known as a ‘scrum’) lasting for 10-15 minutes maximum, where each person states what they did yesterday, what they are going to work on today, and whether they are experiencing any blocks. IT Development Team Leads also attend this meeting and can deal with any blockers as needed. Typically, a team lead is also ‘scrum master’ and will ensure everything is kept brief and within the time limit and any blockers dealt with offline.
Note that during Requirements Elaboration (see 5 above) business analysts and key business stakeholders may also choose to hold their own daily stand-up meetings as well, to ensure they are on track for getting their user stories ready for the next sprint planning stage.
At the End of each Sprint
At the end of each sprint, in the week following that sprint, two main activities are undertaken:
a) The Development Team may hold a sprint demo. This is where they can share screens with key SEKO stakeholders to demonstrate what they have delivered during that completed sprint. This provides the business with ongoing visibility of the system as it is being built.
b) The Development Team Leads may hold their own internal sprint retrospectives. This is where they look at the user stories that were planned to be included in the completed sprint and compare with the user stories that were delivered. This can be assisted by sprint ‘planned vs actual’ burn-down charts (JIRA has good tools for this). This helps the development teams with gaining experience on actual time taken vs the story-points effort estimations and therefore to provide more accurate estimations during future Sprint Planning meetings.
Overall Agile Process Cycle
The above process should repeat on a regular weekly or bi-weekly cycle as described, with user stories being prepared with enough requirement details in time for each new development sprint. The whole flow is illustrated in the following diagram, and the pattern can be repeated for as many sprints as needed to deliver a whole Phase.
