|
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 using Lightcast French and Italian job postings, I want to be able to analyse with the Lightcast Occupations Taxonomy, so I can gain rich, comparable analysis with our English language data.
During PI-2 models were developed for LOTv6 in French and Italian and (hopefully by the end of PI-2) subjected to initial quality analysis. During PI-3 we want to continue this work and identify the creation of rules and a mechanism for their maintenance and operation, with the ambition of QA and deployment of French and Italian LOTv6 to reasonable quality levels during PI-4 (depending on how this work goes).
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?
Global customers and customers within France and Italy will be able to benefit from the richness and cross-country comparability of LOTv6.
Sometimes we do things for our own benefit. List those reasons here.
LOTv6 represents a substantial asset to Lightcast and we want to maximise its return by making it usable across different languages. This work represents initial moves in this long term direction, with the aim that we can use it as a model for scaling to further languages.
Who are we building this for?
All Lightcast user categories.
How will users receive the value?
Eventual delivery will be via Global Postings and Spotlight.
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?
To be determined by the time the Epic begins, but establish benchmarks for levels of precision and recall for LOT to be launch-ready.
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.
<FigmaLink>
Consider performance characteristics, privacy/security implications, localization requirements, mobile requirements, accessibility requirements
Is there any work that must precede this? Feature work? Ops work?
Just answer yes or no.
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
Focus on risks unique to this feature, not overall delivery/execution risks.
What are you still looking to resolve?
|
Are there direct costs that this feature entails? Dataset acquisition, server purchasing, software licenses, etc.?
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.
Team | Effort Estimate (T-shirt sizes) | Jira Link |
---|---|---|
Analyst Red, Documents, Data Production, etc. | Small, Medium, Large, etc. | Type /jira to create a link to an epic or issue |