Helastel are Agile. Where appropriate, we follow an Agile software development process. Being Agile provides us with the ability to create and respond to change in order to succeed in an uncertain and often turbulent project environment.
Agile software development is an umbrella term for a set of methods and practices based on the values and principles described in the Agile Manifesto. Our projects evolve through collaboration between self-organising, cross-functional teams utilising the most appropriate practices for delivering against our customers requirements.
In 100% of cases, arriving at the software you really need comes as the result of intensive and purposeful scoping to ensure it’s fully aligned with your business.
Our efficient software scoping methodology is designed to:
- Streamline the shape of your software project.
- Reduce friction in subsequent development processes.
- Establish your deepest requirements.
- Agree the objectives that will deliver the most meaningful change.
This is where our business analysts listen to your requirements and understand your journey so far. We’ll ask probing, difficult questions that get at what you really need; addressing root causes rather than treating symptoms. This frequently contradicts what our customers thought they needed. You’ll be glad it did. The result is a documented consensus on the key factors for success and a suggested approach for getting there, with budgets and timescales.
People are distinctive, fallible, unpredictable, and they will use your software! We call types of users, ‘personas’, and we study how they share habits, thinking frameworks and assumptions. They will view things differently from you. We’ll figure out exactly how.
What personas look like
Each persona has a unique name like Payment Chasing Pauline or Meeting Planner Martin. Additional background information is used to describe each persona, much like a personal biography. These can be incredibly detailed even including information such as:
- Photograph (Strange but true! This helps the persona ‘come to life’ in the imagination of the wider team)
- Career History
- Professional Qualifications
- Working Environment/Habits
- Personal Goals
- Common Tasks
- Typical Motto/Quote
Once we’ve established who the software is for, we nail down every business process, sales journey and other dependency, and draw up priorities. This is the process of uncovering ‘epics’, each of which describes a broad functional capability such as “secure portal access for online storage” or “searchable product catalogue”.
Again, this typically goes beyond the customer’s preconceived project parameters, and for good reason. It’s a complex undertaking but there are two simple outcomes:
- A shopping list of features, corresponding with the needs of prioritised personas.
- A definitive vision for the software, its users and its capabilities.
Why is it called an ‘epic’?
The business end of a scoping exercise comes with the definition of lots of distinct user stories (see below), each of which translate into instructions for software development. The name “epic” means a long narrative (think poem or novel) and is apt in the minds of software developers as it also represents the large chunks that much smaller “stories” are carved out of.
Software Scoping Process
The scoping process to this point has dealt with the project as a whole. Subsequent stages are repeated for each phase of software delivery to maximise quality and efficiency, and evolve the MVP.
User stories are use cases. In no more than one or two sentences of everyday business language, each one captures what a persona does, or needs to do, in each of its interactions with the software. Every story is accompanied by simple acceptance criteria, used to test that the finished software meets its set requirements.
User story: I NEED TO amend an order before it goes out for delivery SO THAT I CAN make sure I don’t get charged for stuff I don’t want
Acceptance Criteria: Customers can change in-progress order details and receive notification of new order basket/delivery date.
This approach produces an unambiguous set of laws by which all development decisions are managed. Software developers apply detailed technical system requirements to each user story before writing a single line of code.
Scalability & Infrastructure Requirements
Software needs hardware to operate within, so scoping infrastructure requirements upfront is extremely important. With these parameters fully investigated, software developers can create a product that is fully attuned to its environment. We’ll ascertain requirements including:
- Scalability – how big the software needs to be; how much room to grow
- Capacity – how many concurrent users; how much processing
- Latency – how fast/responsive to user commands
- Availability – how close to 100% uptime is essential
- Risk – what security profile is most applicable
- Governance – which specific compliance mandates must be met
Minimum Viable Product (MVP)
The MVP is the holy grail of the scoping process; the pure essence of your software project that defines the foundation release for all subsequent software versions. Think of it as the Google page-ranking algorithm, the Starbucks espresso, the KFC secret blend of herbs and spices - emerging as the conclusion to the user story process. Bear in mind that going live with an MVP allows you to get your software up and running in less time with fewer costs, with plenty of scope to add more functionality later.
Having tested business objectives, explored functional dependencies, identified user personas and defined precise, unequivocal requirements in straightforward business language, the project is now robustly optimised to enter software development and produce successful results. This can include a full roadmap for staging delivery into prioritised phases or as a single release.