Webinar
In traditional project management, the primary driver of all action is the deadline. Managers will carefully draw up a plan of action, dictating what needs to be done when (or how many hours should be applied here or there) and will monitor progress towards that goal. Each sub-task will have its own due date and, as long as all tasks are completed on time, the project should be a success.
Since Agile’s entire philosophy is around empowering employees to quickly and effectively deliver value, it should be no surprise that Agile teams do not conduct projects in the same way. With simplicity and effectiveness at the core of Agile, projects are neatly split into 3 to 4 tiers: Themes, Epics, User Stories, and Tasks.
Tasks are the smallest units of work in a project. These are the items on each team member’s “to do” list and represent the actual work completed on a daily or hourly basis. Over the course of an Agile iteration (or sprint) the sum of these tasks should achieve one or more user stories.
The objective of every iteration is to produce a tangible, value-adding and operational product element for the stakeholders. This might be a specific software feature, or a technical design, a prototype, a draft, a piece of content. Something the customer can actually quantify, assess and use. This output from an iteration is a user story.
Once multiple user stories focused on the same high-level objective have been developed, these represent an epic. Epics describe a large set of requirements designed to reach a major milestone for the project. This could be a major feature release, the launch of a marketing campaign, or building a finished product.
Finally, we have themes. Themes represent the long-term strategic objectives of the business. They are the high-level goals from which all epics and stories cascade. For example, a theme for a marketing agency might be “Increasing revenue from our Paid Advertising service.”
The company would then outline a series of epics which would contribute to this larger strategic goal. For example:
While teams might work on dozens of stories a month, they might complete only a handful of epics every quarter.
ADDITIONAL LINKS
Also known as “projects”, it’s crucial that epics clearly describe a business goal. If the customer was to scan all of the epics, they should essentially see a list of their biggest priorities.
In traditional project management, project objectives (and indeed the smaller tasks which make them up) are dictated by management. While in Agile it is generally the product owner’s responsibility to write epics, they are usually created with input from all team members and stakeholders. This has the dual benefit of ensuring the customer’s requirements are accurately captured, but also ensuring that team members fully understand the job in front of them.
Flexibility is key
One month is about the minimum time we would expect for completing an epic. This would span multiple sprints or agile iterations. It’s important to remember that over this period, the epic can change.
Once again, we come back to a fundamental principle of agile: constantly learning and delivering what the customer wants. If the customer provides feedback around changing the final scope or objective, the epic (and subsequent user stories) can be changed to reflect that.
Some Agile teams will not follow the theme, epic, story format. They might phrase these tiers differently or apply a totally different format. That’s one of the beauties of Agile: the core principles can be effectively applied in a virtually limitless number of ways.
With that in mind, we wanted to share some core steps that any team can take in order to implement an Agile project. These steps are valid across any Agile framework or adapted framework.
Create a project vision
Agile teams don’t build for building’s sake: they build in order to achieve a large and specific goal through iterative steps. Team members should always have the bigger picture context in order to understand what they’re building towards. This is integral to successfully adopting the Agile methodology.
Build a roadmap
What are the customer’s requirements? What are the stakeholder requirements? What are the user’s requirements? How will your team build the bridge that connects all of these needs while still fulfilling the project vision and creating a reasonable workload?
The roadmap is your high level “best guess” of how the project is going to play out. This can be regularly updated to reflect progress and learnings.
Map out iterations
At the outset of every iteration (or sprint) it’s crucial that team members know what they’re expected to deliver and why.
Run daily standups
To keep employees accountable (and to maintain open communication and transparency) you should run short, daily standups. These are informal meetings where every team member provides a concise update on their progress, shares any roadblocks or asks for help. This also gives the product owner (and therefore the main stakeholders) a crystal clear understanding of project progression.
Review progress
After each iteration or sprint, it’s crucial to spend some time reviewing how it played out. Did anything go wrong and can we prevent this from happening in future? What worked particularly well? Are there lessons we can take into the next iteration? Use this time productively and your team will benefit massively going forward.
The most important skill when it comes to writing user stories is listening. The customer is going to explain what they want, and it’s your team’s job (and principally the product owner’s job) to translate that accurately into user stories.
The following are tips on writing user stories that accurately capture requirements and are as actionable and clear as possible:
Stories follow epics—The epic is essentially the vague overview of what the customer needs. Stories are the highly specific elements which will enable the epic. So it’s important to always start by defining the epic, and then writing user stories (and then writing tasks) which will realize the epic.
Once you’ve written your stories, use the INVENT system to check their quality:
Testable—You must be able to test your user story in line with quality assurance standards.
We’d be happy to provide a bespoke 1:1 demo on how Cloud Coach can benefit for your business.
