On a less complex system our developers will move straight from the Discovery Stage into prototyping each product.  In the more complex systems that we usually develop, we produce our information hierarchies and user stories. We always work with the end user to produce a prototype that reflects the user’s and stakeholder’s input and meets the business requirements and needs.

User Stories, Themes and Epics

User stories are the building blocks of Agile projects, and often combine into themes and epics. A user story is a self-contained unit of work agreed upon by users and developers. A user story is usually only a sentence or two long, and can be determined by asking:

  • Who are you and what is your role please?
  • What do you want the system to do?
  • Why do you want it to do this?

Our Product Owners work with users through a series of workshops to both build up and break down epics into user stories that are concise, usually only a sentence or two. We usually put each user story onto a small card so that our scrum team can monitor the progress on our Srum board.

A Theme is a group of inter-related stories, often with a common goal, or a common relationship. While some stories in a theme may be dependent on one another, they do not need to encapsulate a specific workflow, or need to be delivered together. Often, user stories are grouped into themes to support prioritisation of the product backlog, to deliver a measurable sense of business value. An epic may look like a big story, or a large group of stories describing an outcome, usually with a complete workflow for a user. The significance of an epic is that business value of individual stories is often not realised until an entire epic is complete.

Breaking down epics into user stories, we get the definition: “This particular user wants this part of the system to do this because it will solve this problem and this is what we need to do to ensure acceptance of the product”.  A perfect and succinct definition of what and why the system should look and do what it wants to achieve.  Focusing on the goals and finding out the how, why, where and when about the end system is vital.  It ensures that we provide what the business needs and it also produces a smooth, fully utilised working system that the end user will quickly accept and use.  Often, we find some interesting concepts that the other stakeholders had not thought of, so we always value everything a user tells us.

Prototypes

Prototypes are working models of the product that the user can investigate, try out and test. This might be something such as a menu that can be clicked through or an UX to view and comment upon. They are produced during a sprint through an iterative process, where the scrum team work closely with the product owner and users to demonstrate the prototype, and solicit feedback on what is good and what can be improved or changed. Any changes are quickly implemented, and often we find that the outcome exceeds the customers initial expectations.

These iterations mean that the both the user requirements and the systems produced are refined through out the project.  This is how Gaia can be certain that you will receive the system that you requested and one that will meet your user and business requirements.

Incremental

One of the key features of the Agile methodology is that design and development is on an incremental basis.  Each sprint is defined in a time box during which design and development takes place.  We try and keep each sprint lasting between one week and four weeks.  This ensures that the end user sees a product to review very quickly. The incremental nature of an Agile build means the software is designed, delivered and built in several pieces –or products.  The more complex the system the more products there will be, however each product will be a complete subset of the whole system and each will have a recognisable functionality.  On larger projects several products at a time will be produced.  As can be imagined, with this number of products it is important that their development is well planned and managed. Our development teams are well versed in reviewing importance, risk, interdependences and velocity to ensure that products are available to the users in the most appropriate manner.

Keep Planning

Agile is different from Prince 2 and waterfall projects in that under on Agile projects, planning is a continuous process. Before every sprint, we undertake a sprint planning meeting, attended by the product owner, the Scrum Master and the entire Scrum Team.  The objective of this meeting to for the product owner to describe the highest priority features to the team, determine the existing backlog, and plan the products to be delivered during the sprint. Gaia believes that this is a very important part of the planning process.

Gaia believes that every team member has a role to play in planning, and during every sprint, we have a mandatory daily stand up where ‘yesterday, today and tomorrow’ plans are discussed.  During the sprint, we continuously monitor burndown, and work with the product owner to assess themes to ensure that products are reflective of requirements and are delivered in accordance with the changing landscape.  Monitoring the burndown and burnup charts closely allows us to confirm we are still meeting the timescales of the roadmap, and we continually assess developing relationships and information hierarchies.

Obviously User Stories are very important parts of our planning routines. Once we have the User Stories we decide upon their interactions and priorities and then produce a product backlog.  This is a list of the functionality and products that is prioritised by risk, interaction and functionality.

This might also mean that we need to produce Information hierarchies. These are an important part of developing good information architecture. They focus on the relationships between the different parts of the system and how they relate to each other.  They are obtained when we ask questions of the users during our workshops.

After every sprint, and at every opportunity where feedback in received, we revisit and review our plans.

“The response to the chromosome matching game has been fantastic. It shows people coming back to the stand again and again to play it and try to improve their score. As an engagement and educational tool, we couldn’t have asked for more.”
Angela Burgess, Education & Engagement Project Manager, Wales Gene Park, Institute of Medical Genetics

Design Case Studies

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close