How you engage in discovery consulting phases with the right mindset can make a huge difference.

At Alliance Systems we get asked to review and participate in various digital transformation opportunities.  Ultimately, we have the same conversation frequently… what came first, the chicken or the egg?  By this we mean the dreaded question… how much do you think this product will cost to design and build? And how long will it take to launch?

How agencies answer this question can differ greatly, but our favorite answer is…

“We fall in love with the problem first!”

Who is this blog article for?

If you are a business owner, founder of a startup, or executive wanting to lead any kind of software application life cycle… this article will help you understand and identify successful tactics to plan and estimate your initiative.  And while there are various methodologies and exercises that can be included in a discovery phase, we are sharing some of our experience and insights with how we generate plans.

This document breaks down the approach and planning process used to prepare for agile development production cycles.  We combine the best of proactive planning and agile to deliver results.  This includes all of the following topics:

Organize Icon

How Documentation is Organized

» Cadence
» Epics
» Stories
» Spikes
Epic Wheel Icon

8 Critical Elements to Documenting Epics

» Flow Diagrams
» Business Logic
» Content / Data
» Stories / Spikes
» Acceptance Criteria
» Risk Scores
» Confidence Scores
» Triage
Roadmap Icon

Delivering an Agile Charter: 90 Day Roadmap

» Estimate and Timeline
» Teams and Roles
» Executive Breakdown
» Success Criteria
» Committed Objectives
» Exclusions and Risk

How Documentation is Organized?


The goal for planning any agile development initiative is not to over plan.  This can be wasteful, as there are many “unknowns”, which cause you to throw out the plan as soon as you start.  Our recommended cadence is planning in terms of 90-day cycles.  This creates momentum throughout the year when planning through all four quarters.

Within the 90-day cycles, we recommend smaller development cycles which deliver completed pieces of functionality.  These smaller cycles are referred to as sprints.  We define each sprint as a two-week development cycle.

The main two macrolevel goals for any discovery should be:

Work Break Down

The following is our approach on breaking down information for any initiative:

The global initiative as a completed executable with all functional counterparts.
Overview of high-level tasks that have to be completed to produce a deliverable.
Collection of tasks that are grouped in design, development, or business-centric.
R&D for collection of additional intel, in order to make better informed decisions.

Here is an aerial view for the organization across Epics, Stories and Spikes.


8 Critical Elements to Documenting Epics

Epics contain two vantage points.  The first is a tactical flow for documentation, essentials that many methodologies take into account.  The second is a strategic flow for teams to be involved and have transparency about the expectations for what is included into committed objectives and the roadmap.

Epic Documentation Chart

Flow Diagram

Flow Diagram

While written documentation is the base for any initiative, it is considered best practice to also include visual flow documentation wherever possible.  When people read, they create a visual representation in their mind.  However, when flows are visualized, it allows the entire team to have the same visual as reference.  This provides a sense of transparency so that various people involved can all participate and understand how systems interact with users.
Business Logic

Business Logic

Documenting core business logic is an essential exercise. Whether it’s an algorithm, a templated formula, or a standardized way to manipulate data/numbers. Business logic can range from simple to complex based on a variety of factors and conditions necessary to perform system functions. A great approach is to break down sets of business logic based on users. After all, different users can participate at various levels with different roles. Understanding their journey and how the system provides results for them to accomplish tasks is critical to understand.
Content / Data

Content / Data

It is very challenging to develop strategy around business logic when you haven’t appropriately considered all the content and data that will be used. Understanding the schemas/models and organizing relationships between all data can be a powerful source of documentation. Engineers that help with system architecture and that are responsible for generating frameworks that are scalable will more than likely create ERDs (Entity Relationship Diagrams). In many instances, this becomes the foundation for database design.
Stories / Spike

Stories / Spikes

All Epics have a further break down to organize tasks into logical groupings. These stories have more details and include story point estimates. These are estimates that production team members such as analysts, designers, front end developers, back-end developer complete together as a team. No one individual is responsible for an estimate. The best approach is to estimate per the experiences of various experts and production specialists, so there is an average which mitigates risk.

Stories, while similar to Epics in format, are essentially smaller groupings of project documentation that go into more detail. Stories will contain information, written from the perspective of a user within a journey, that is clear so that a designer or developer can deliver completed modules and tasks required to complete an Epic.

Spikes are specialized tasks that require additional research or gathering of intel to make informed decisions. From R&D, to building a quick proof of concept, to interviewing users for feedback, there are various reasons to call out a Spike. Once Spikes are completed, you can consider any final contingencies or dependencies for further Stories being developed.

In order for an Epic to be complete, all Stories and Spikes within the Epic need to be finalized.
Stories / Spike

Acceptance Criteria

Acceptance Criteria is a list of all items that need to be carefully considered for a Story to be considered done. Planning acceptance criteria ahead of time mitigates risk and any confusion or surprises. As designers and developers completed their tasks, they will perform an audit against the acceptance criteria list. All items in the list must be accounted for before something is ever accepted as done.

While it is impossible to cover every single last detail, this exercise is very helpful and provides transparency and accountability across all teams including stakeholders, product owners, and final production team members.
Risk Scores

Risk Scores

As Epics are generated and documentation across both tactical and strategic flows are being fulfilled, team leads are allowed to vote on risk scores. We use a scoring system between 1-5 (1 = little to no risk, 5 = significant risks identified). Documenting and sharing risk details and scores for each Epic is important. Especially as it relates to the decision of alternative solutions or whether or not an Epic should be started in the first place.

Scores for risk are also reviewed from multiple vantage points across a variety of team members. Transparency and listening to all experts on the teams is important. If risks scores are high, a good exercise to think about is calling out Spike(s). There might be more intel, alternative options for resolution, or choices that could lower risk per additional R&D.
Confidence Scores

Confidence Scores

While confidence scores may sound similar to risk scores, but they are different. Confidence scores are meant to decide which committed objectives the development team should move forward with inside a 90-day production cycle. Meaning, what is the level of confidence everyone has that we can in fact complete the Epics selected within the supported timeframe.

It is really easy for teams to overcommit. Therefore, it is another team related exercise to be disciplined and engage in the tasks that are most important. Ultimately, it comes down to a balancing act between what is needed, what is wanted, and what are wows (bells and whistles).


Once all other 7 elements of an Epic are determined, Triage is the final step. This is where dependencies, contingencies, and Spikes are considered based on Risk/Confidence. The goal of triage process is to create the best sequential order for all tasks to be completed within the roadmap.

With agile teams, the triage process will be repeated several times as sprints are completed. Teams with great communications, documentation, and established process for digital transformation projects will have a wholistic view and always work in a balanced fashion to accomplish all tasks. There has to be flexibility built in.


Delivering an Agile Charter: 90 Day Roadmap

Completing a discovery for an initiative is like getting blueprints from an architect.  Ultimately, you come out with two main results:

When Alliance Systems completes a discovery consulting phase, we deliver a final document called an Agile Charter.  This charter organizes a lot of information into the following sections:

Estimate and Timeline

Estimate and Timeline

Estimates are delivered and broken down per Epic. Estimates also have ranges based on best-case, planned-case, and worst-case scenarios. The goal being that there is always some flexibility built-in due to potential unknowns. This allows clients to understand the range of potential costs during the development cycles.

Agile teams should be responsible for tracking metrics and costs in an ongoing basis from Sprint to Sprint. Full transparent communications will surface awareness around project status and financial projections at all times through the product life cycle.
Teams and Roles

Teams and Roles

The charter will clearly provide details on the team. Agile teams are best defined as cross-functional units with experts and specialists in various areas. The client should get a clear view and understanding for the talent, skills and responsibilities assigned within the initiative.
Executive Breakdown

Executive Breakdown

In order for teams to be on the same page and execute as one, they need a very clear vision. This is a global set of information that uses plain simple English to describe the challenge and outcomes that will set the product apart.
Success Criteria

Success Criteria

Very similar to acceptance criteria, the Charter will include a list of all success criteria defined at the highest level. Once all Epics are completed, the results are audited against the success criteria list. This exercise can also help carry on the momentum on projects that are large and require more than 90 days to launch. Success Criteria can act as a passing of the baton across each quarter in the calendar cycle.
Committed Objectives

Committed Objectives

Within the Agile Charter, this is essentially the list of all Epics that are documented and ready for execution within a given 90-day timeline. Epics contain flow diagrams, business logic, content/data, Stories, Spikes, Acceptance Criteria, Risk Scores, Confidence Scores, and Triage documentation.

Understanding the connection and needs for all Epics to be executed, provides a working roadmap that will need to be completed within a 90-day window.
Exclusions and Risk

Exclusions and Risk

As with many agreements and project documentation, there can be exclusions that are highlighted for clarity. These are clearly stated limitations or items that will not be included during the production timeline defined. Global risks to the entire initiative are highlighted at the beginning, so all parties are held accountable to the same criteria even though the agenda is flexible and agile.


In conclusion

Discovery planning isn’t just asking great questions and documenting answers.  If done correctly, it sets a foundation for protocols on how to communicate, how to commit to objectives and how to handle “unknowns” once you begin your journey.  Our clients love our process because it is fair and equitable for all parties.  We believe documentation should be transparent and non-political.  If done correctly, it should provide all teams with informed status at all milestones until launch.



Interested in learning more about how our discovery process can aid your project?