Customer/User Job-to-be-Done or Problem

The Scope of the user problem should be narrowed to the scope you are planning to solve in this phase of work. There may be other aspects you are aware of and plan to solve in the future. For now, put those in the Out of Scope section.

When [user situation/context/mindset], I want to [user need/goal], so I can [expected result/outcome].

As an institutional researcher, I want Lightcast to minimize processing time, so I can start using my results more quickly.

Value to Customers & Users

In the JTBD framework, these are the “pains” and “gains” your solution will address. Other ways to think about it: What’s the rationale for doing this work? Why is it a high priority problem for your customers and how will our solution add value?

Customers will be able to receive an initial version of their data more quickly, and they will be able to review and understand their data before deciding how much effort they want to put into providing what Lightcast would need in order to give them more or better data.

Value to Lightcast

Sometimes we do things for our own benefit. List those reasons here. 
Currently, AO team members have to copy and paste commands and adjust them for a particular customer project every single time they run a processing program (except the matcher). Nearly all of that information can be created at the beginning of a project and reviewed once before usage, which will save time entering the same information in multiple commands, and time spent rerunning programs because of manual errors. In addition, this will prepare the way for moving automated processes into a Gitlab pipeline, which will require that custom characteristics are stored in a config file (See Alumni Pathways: Create the production pipeline for pre-match processing scripts (Phase 1) ).

Other benefits of each customer project taking less time and effort to process will be our improved ability to classify AO 2.0 as Annual Recurring Revenue, scalability (supporting more customers with same size team), and flexibility to better serve a customer by rerunning all or a portion of the pipeline when it is advantageous to do so.

Target User Role/Client/Client Category

Who are we building this for?

User is Lightcast AO Team staff members, but all AO 2.0 customers would benefit.

Delivery Mechanism

How will users receive the value?

Standard AO process.

Success Criteria & Metrics

How will you know you’ve completed the epic? How will you know if you’ve successfully addressed this problem? What usage goals do you have for these new features? How will you measure them?

Success is defined by being able to run all processes from pre-verification through creation of the processprep input file, plus all processes after completion of semi-auto processing, via a single config file in place of the current multitude of command line entries.

Aspects that are out of scope (of this phase)

What is explicitly not a part of this epic? List things that have been discussed but will not be included. Things you imagine in a phase 2, etc.

Anything needed in the config file for the use of processing tools that have not yet been built (e.g., tools to replace or enhance processprep-process1-process2 pathway)

Solution Description

Early UX (wireframes or mockups)

<FigmaLink>

Non-Functional Attributes & Usage Projections

Consider performance characteristics, privacy/security implications, localization requirements, mobile requirements, accessibility requirements

Dependencies

Is there any work that must precede this? Feature work? Ops work? 

Completion of several input processing scripts that are currently in process of development by Ariah Holevoet of Raptor team (expected by end of December), and potentially design decisions after review of current process by Daniel Meyer (expected by end of November).

Legal and Ethical Considerations

Just answer yes or no.

High-Level Rollout Strategies

• Initial rollout to [internal employees|sales demos|1-2 specific beta customers|all customers]

  • If specific beta customers, will it be for a specific survey launch date or report availability date 

• How will this guide the rollout of individual stories in the epic?

• The rollout strategy should be discussed with CS, Marketing, and Sales.

• How long we would tolerate having a “partial rollout” -- rolled out to some customers but not all

Risks

Focus on risks unique to this feature, not overall delivery/execution risks. 

Elimination of most of the manual review will risk GIGO problems, which would be easy to ignore until a great deal of damage is done.

Open Questions

What are you still looking to resolve?

Complete with Engineering Teams

Estimated Costs

Direct Financial Costs

Are there direct costs that this feature entails? Dataset acquisition, server purchasing, software licenses, etc.?

Team Effort

Each team involved should give a general t-shirt size estimate of their work involved. As the epic proceeds, they can add a link to the Jira epic/issue associated with their portion of this work.