You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

Hints / Steps for Breaking Things Down

  1. Read the Epic carefully - try to visualize the full picture of what it would need to provide. Are there steps needed that are not covered by the existing tickets?
  2. Read an issue that you suspect can be broken down - watch out for any Red Flags (listed below)
  3. If you identify a Red Flag, try to think of how to make that part of the issue standalone - NOTE: it is ok for issues to form a hierarchy or to depend on one another
  4. Write a new Story based on the subset of work you've identified, and then link it back to the original ticket
  5. Check the original ticket again to remove any text / feature that is now covered by the new ticket(s)

NOTE: If you do manage to tease out one or more new issues, link it back to the original by clicking Link Issues and choosing "split from" or "split to"

Warning Signs / Red Flags

The following may not always be a bad thing, but they can indicate an issue that can be further broken down

  • Singleton Epic - an epic with only a single Story is either too small to be an epic or too large to be a story
  • Not enough details - very short ticket text with a very high estimate makes us wonder where those extra points are coming from
  • Commas / Conjunctions (e.g. and / or / but) - can indicate a pause or change in focus
  • "also" / "as well" / "includes" / "including" - extraneous things that can usually be split into separate tickets sometimes use these types of modifiers
  • a single Story requires changes to multiple repositories - typically Stories can be broken down such that they only need to change 1 repo at a time (if they can't, this may indicate coupling or issues maintaining the "separation of concerns")
  • A clear disconnect or confusion between what was asked for in the ticket vs what was suggested by leadership - this indicates that one or more people did not understand the full scope of the work requested
  • ... and many more

Case Study: Improve Extractor Catalog

See https://digitial-product-engineering.atlassian.net/browse/SIMPL-115

Epic: Improve Extractor Catalog

Description
Catalog of extractors that provide extractor name, description, version, authors, rating, comments.


Acceptance Criteria - SIMPL
None

Original Story Text

Description
Catalog of extractors that provide extractor name, description, version, authors, rating, comments.


Acceptance Criteria - SIMPL
None

Original work discussed/requested for ticket

  • Expand admin-only Extractor Catalog to make it public
  • Add additional information to this view (e.g. version, rating, comments, etc)
  • NOTE: While there were lots of unanswered questions, this discussion did match up fairly well with the original ticket text 

Red Flags encountered

  • Singleton Epic (Epic had the exact same text as this issue, verbatim)
  • Not enough details (it's not even a complete sentence)
  • Commas (first four items with commas are closely related, but the other two are not)

Suggested Split

Case Study: View Extractor runtime synopsis and granular metrics

See https://digitial-product-engineering.atlassian.net/browse/SIMPL-41

Epic: Extractor Job Management

Description
Dashboard of job operations where a space admin can view number of jobs running, waiting, and failed. A user can also view the history of a job and see its log files, status events, messages, resource allocation (memory usage, cpu usage).


Acceptance Criteria - SIMPL
None

Original Story Text

Description
As a Developer, I want to be able to gain greater compute insights of my extractors in real time to better optimize resource allocation and scheduling so that I can better profile the behavior of my extractor

Syngenta Comments:

NCSA Comments:
1) UI/UX and backend dev: 2 weeks
2) API dev: 1 week

Min Estimate (Weeks): 3
Max Estimate (Weeks): 3


Acceptance Criteria - SIMPL
None

NOTE: this is not a full Story. We only know the who/what/why but nothing about the "how" or "where". This can cause the estimate of "when" (e.g. the story estimate) to be significantly skewed.

Original work discussed/requested for ticket

  • Expand Clowder UI to group Extractions not only by extractor, but also by an ID that is unique per-execution
  • NOTE: This did not seem to clearly match up with any of the text in the original ticket

Red Flags encountered

  • Short text with a high estimate - ticket contents should justify the estimate
  • Disconnect between ticket text and what was asked for
  • Required changes to multiple repos

Suggested Split

  • No labels