Project requirements and priorities are always changing, so only through effective collaboration can the delivery of a product or service stay on the right path. Agile methods, such as Scrum, DSDM or Kanban have all helped bring stakeholders and engineers closer together. Esparter and its network of associates are all experienced in the latest agile techniques and will discuss these with you to determine which are the most appropriate for your project and vision.
Before software can be built the developer needs to understand what should be built. This involves understanding both your business goals (as the primary stake holder) and the goals of the end-user. Shared understanding needs to be established from the start.
The aim is to do just enough planning and analysis to be confident that development can start. Generally this will take one or two weeks and is analogous to the “feasibility” and “foundation” phases in DSDM. It involves a series of collaborative workshops where stakeholders agree on scope, objectives and a plan. It may result in extra research or prototyping activities. The kickoff should contribute the following:
- Project vision, success factors and define key performance indicators (KPI’s)
- Understanding of the business goals and the desired impact on user behaviour.
- Categorisation of system users – so that personas can be established
- List of the usage scenarios and user journeys – in the form sketches and user stories
- First draft of an (adaptive) project plan including release schedule and a user story map or MoSCoW categorisation
- High level definition of system architecture, technology and test strategy.
- Identification of Risks, Assumptions, Issues and Dependencies (RAID)
- Definition of project governance and working methods
Return on Investment and the 80/20 rule
Also known as the Pareto principle, the 80/20 rule applies to the business value created by the features of a system. 80% of the value of a system comes from 20% of those features. Our primary concern is that, with your help, we identify that magic 20%. The priority is then to deliver that 20% as quickly as possible without being slowed down by other (less important) features.
The purpose of discovery is fast learning. We’ll use sketches, wireframes and mockups to get fast feedback. The designers work closely with product owners and stakeholders, constantly reviewing design ideas and approaches.The high level user stories are broken down and fleshed out, creating a focus for collaboration.
For delivery the focus moves to predicability and quality.
After discovery we’ll formalise the user stories, adding specification by example which captures business rules and requirements in a plain english format. This creates a ubiquitous language that is shared between developers and other stakeholders and helps remove ambiguity. With the use of a standard Given-When-Then format we can create code that will test the system. These tests form part of the acceptance test suite and double up as living documentation
As soon any new feature is available we’ll ask for your feedback, combine that with any automated user feedback statistics and use that for improvement.