/
DRAFT - Vega - Team goals for Spikes

DRAFT - Vega - Team goals for Spikes

This page is to express Team Vega’s primary objectives for Spikes and when to use them.

Primary objectives

  • Reduce, excess uncertainty for Jira tickets:

    • Is the resolution of a Feature / Task / Bug excessively uncertain?

    • Do you need an answer on question before starting on the Jira ticket?

    • Is the UI or technical approach achievable

Key article to consider when considering a Spike - Agile teams learn from spikes: time-boxed research activities

Note related to primary objective for Spikes: Objective is to reduce, not eliminate uncertainty

Recommended process

  • Vega developers review Jira ticket for up to 2 hours, and if there is still a question, a Spike is created.

  • PO, QA, and SA will take these steps

    • Provide all known screenshots and / or logs available

    • Provide clear description

  • Utilize buffer time in Sprint, if possible, to continue research and / or pull Primary issue into Sprint

Key components of Jira Spikes

  • [List created by Team] - clear description (What exactly need to do in scope of spike and what result should be)

Optional format for Jira Spike tickets - Folijet - Spike Template

Spike related actions

Once a Spike is created:

  • Immediate action item

    • Tasks/stories (if applicable) should be blocked by Spike

  • Documentation

    • Document all Spike findings in either the description or Comments of the Spike

    • Ask Team to review them (if applicable)

  • Code Accessibility (if applicable)

    • Check code into GitHub to make it accessible to the entire team.

  • Follow-up Actions

    • Create / edit existing User stories to implement or formalize the preferred approach or solution within the original Jira issue (if applicable)

    • Share the resulting Jira issues with the PO for awareness so they can ensure the issue metadata (labels, features, etc.) is accurate and complete.

  • Acceptance and Recording

    • The PO and / or the architects' team are responsible for accepting after Spike findings are presented and discussed.

  • Closing spikes and / or tasks/stories

    • A Spike can be Closed as Done by developers following a review by second developer if it is a technical task or by PO/SM if confirmation is needed, for example, of business logic, etc.