Webinar
Capabilities include project timelines, resource management, and stakeholder collaboration.
Manage, track and enhance your project delivery processes efficiently.
Manage account goals, tickets, and stakeholders while gaining full customer journey insights from onboarding to renewal.
Everything you need to run your projects on Salesforce. Choose from Waterfall, Agile or Water-Scrum-Fall, track time and use repeatable project templates.
-
Solutions
Capabilities include project timelines, resource management, and stakeholder collaboration.
Manage, track and enhance your project delivery processes efficiently.
Manage account goals, tickets, and stakeholders while gaining full customer journey insights from onboarding to renewal.
Everything you need to run your projects on Salesforce. Choose from Waterfall, Agile or Water-Scrum-Fall, track time and use repeatable project templates.
-
Features
-
Resources
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.
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:
- Investigate and describe our ideal customer “persona”
- Launch cold marketing campaign to obtain new leads
- Test alternative pricing strategies
While teams might work on dozens of stories a month, they might complete only a handful of epics every quarter.
ADDITIONAL LINKS
How to create Epics
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.
Core steps for implementing Agile projects
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.
How to Write Effective User Stories
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:
- Use casual language—Stories are not technical specifications. It is a simply written and accessible description of a user need, and should not include any technical jargon.
- Users come first—Stories are entirely about capturing the user and customer’s requirements and expectations for the product. Stories should therefore always be written from the user’s perspective. Use interviews or surveys to capture this information and never make assumptions.
- Leverage personas—While they’re called user stories, the requirements usually come from the customer rather than the end user. An effective technique for getting “end user” input is to create personas. These will include the relevant characteristics, opinions, needs and behaviors of real-life users.
Whenever your team writes a user story, ask does this meet the needs of our user personas? If not, revise the story.
-
- Collaborate—User stories are not set in stone. Over the course of a project, the requirements for specific features or even the nature of the epic itself can change. You should proactively work with customers to capture any changes to requirements or embed feedback, then improve or change stories as needed.
- Who, what, why—To help keep your stories simple, you can follow this format: As [persona] I want to [action] so that I can [benefit]. User stories do not need to be any more complicated than this.
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.
Validating stories with the INVENT system
Once you’ve written your stories, use the INVENT system to check their quality:
- Independent—Each user story describes a unique requirement, which allows the team to tackle them in any order. Make sure your stories do not overlap.
- Negotiable—Another word would be “flexible”. Every user story should be amenable to change based on customer feedback.
- Valuable—Can you describe the exact value this user story brings in meeting the relevant epic or customer requirements?
- Estimable—Make sure stories aren’t open-ended. You should be able to estimate how much effort each story will require, so that each iteration can be planned.
- Small—The maximum size of any user story should, in general, be the duration of a single Agile iteration or sprint.
Testable—You must be able to test your user story in line with quality assurance standards.
Helpful Resources
See Cloud Coach In Action
We’d be happy to provide a bespoke 1:1 demo on how Cloud Coach can benefit for your business.
