Epics are organized around quarterly goals and OKRs (Objectives and Key Results). User Stories are rolled up into Epics and Epics then tell the story at a higher level of how you got to the current state of a feature or product.
With Agile Epics, development teams utilize estimation frameworks instead of time as in Waterfall methodology.
The organizational culture and makeup of teams will dictate the size and granularity of an Epic.
User roles or personas are the best place to start with unique User Stories tailored to each user. Examples would be: “customize content after login” and “allow quicker checkout for platinum members with credit card on file”
If the Scope of Work is measured in weeks or longer, the work should roll up into an Epic. Design Stories should be completed in one Sprint or less.
Epics utilize Burndown Charts to visualize progress, and keep everone informed as to progress. Burndown Charts show the amount of work performed and work remaining to be completed in Sprints and Epics. The x-axis represents time, and the y-axis represents User Stories.
Atlassian has tutorials on how to structure Epics: https://www.atlassian.com/agile/tutorials/epics
Agile in software development focuses on self-organizing teams that support the customer’s rapidly evolving needs through adaptive planning, iterative development, early and continuous delivery, and rapid response to change. Agile is well-suited for projects high risk and uncertainty where requirements are consistently changing, and priorities shifting as a result.
Agile advocates for colocated teams.
In Agile, Velocity is the rate at which deliverables are produced, validated, and accepted.
Daily stand-ups are utilized where achievements and challenges of the previous day, as well as plans for the current day’s work are discussed with the team and key stakeholders.
In Agile projects, the phases are:
- 1. Analyze
- 2. Design
- 3. Test
- 4. Build
- 5. Release
Agile projects are iterative, meaning you continuously improve the product and the process to build the product.
There is a relentless focus on Value. Top priority stories are moved to the top of the list for development. Customers get the features they want quicker than in traditional project management methodologies.
Agile projects have lower costs than traditional projects. There are lower rework costs since problems are tackled as they are identified. Risk is lowered due to continuous feedback.
To ensure a Delivery Date, the number of features is uncertain, but the Delivery Date itself is predictable.
Learning Loops leverage the scientific method: Hypothesis>Experiment>Observe/Learn>Repeat/Iterate also known as the Emprirical Method. Plan-Do-Check-Act and Plan-Build-Release also leverage the Scientific Method.
The Waterfall Method utilizes a phase-based approach where the entire Product Life Cycle is planned from the beginning: Analyze>Design>Test>Build>Release The downside to this is you may have planned many features that end up being not necessary. Things also may be harder as the project progressively than originally planned for, and take longer than anticipated, setting you up to be over budget and behind schedule. Change is hard and expensive, hence the need for a Change Control Board. Feedback can take a while for features. Testing can also lag since testers may not be available when you need them. Waterfall is more predictive Command and Control.
With Agile, high Quality is emphasized at all times, and mistakes should be corrected almost immediately.
Agile is a distributed, adaptive process with just enough. Everyone is involved in planning and Project Management work.
Teams are empowered, creativity is encouraged, and continuous learning opportunities are leveraged.
To ensure that you are on track in the Collect Requirements process, often Prototypes are used. Prototyping is a method of gathering feedback by providing a smaller scale model of the product before building it. This allows customers to view the model and provide feedback before you waste too much time and effort on something the customer does not want or like.
There are some potential pitfalls to Agile, including:
– Loss of confidence in leadership if the Agile Product Roadmap is updated too frequently and focus shifts too often.
– If the Product Roadmap is not updated frequently enough, pent-up demand from the market opportunity may be missed.
– Work decomposed in increments too small causes the team to lose sight of the big picture by focusing on the short-term.
Agile projects are organized with User Stories, Epics, Initiatives, and Themes.
- Themes are large areas of focus that span the entire organization.
- Initiatives are Collections of Epics that drive toward a common goal.
- Epics are large bodies of work that can be broken down into a number of smaller User Stories. Epics, in contrast, are few in number and take longer to complete.
Teams often have two or three epics they work to complete each quarter.
User Stories are brief Requirements or Requests written from the perspective of an end user. The development team commits to accomplish a User Story within a 2-week Sprint. Developers may work on dozens of User Stories per month.
Medium has a good article on free prototyping tools: https://medium.com/littleplane/best-free-prototyping-tools-d86696e5de7
Key principles of Agile are summarized in the Agile Manifesto: https://www.agilealliance.org/agile101/the-agile-manifesto/ and the 12 Principles: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
Mitre.org has a great article on requirements gathering for an Agile project: https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developing-requirements