Versions Compared

Old Version 50

changes.mady.by.user TonyC (Unlicensed)

Saved on

compared with

New Version 51

changes.mady.by.user TonyC (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.



  Image Removed

Definition of Done

  1. The User Acceptance Criteria has been met, this includes user acceptance testing.
  2. Unit Testing has been completed.

  3. The code and documentation has been pushed out to GitHub.

  4. This process has been documented in Jira & release notes.

  5. The story has been verified by or demonstrated to the Product Owner.


Process for Creating Story

The Product Owner is responsible for what goes into the Product Backlog. It is a Best Practice for the Product Owner to create all user stories, however, the process that will be implemented is as follows:

  1. The Product Owner, Development Team, Stakeholders, and Scrum Masters can submit a story to the Product Backlog.
  2. The new story shall contain the label DRAFT in the title.
  3. The proposed story shall be written in simple format: As a <role> I want <activity> so that <benefit>.
  4. During Product Backlog refinement, the Product Owner will prioritize the stories for the next sprint.
  5. The Product Owner will add or verify the Acceptance Criteria and Business Value.
  6. The Scrum Master check that the story follows the template.
  7. During Sprint Planning, the Development team will check the story for completeness and determine which stories will be worked on in the Sprint. 


Process for Demonstrating Story Development Progress

The following procedure has been created to help the Product Owner view the progress of stories in an active Sprint.

  1. The Developers shall add comments documenting their progress and any blockers that they may encounter while working on the story.
  2. The Developer shall place a X next to each DOD criteria that has been completed.  This is done in real time as they progress through the story. 
  3. The Developer shall burn down hours they progress through the story.
  4. The Developer shall mark each Task as Done as they complete the task.
  5. At the end of the Sprint, prior to the demo, the Developer shall change the status of the completed story to Ready to Demo.

Process for Closing a Story and Sprint

  1. Developers have burned down their hours and changed the status of their completed tasks to Done.  
  2. Developers place a  (X) mark by the Acceptance Criteria and each Definition of Done criteria excluding the demonstrated to product criteria.
  3. Developers add a link in the story that points to the documentation and GitHub instance.
    The links will be placed in the Conversation section of the Story.

  4. The Product Owner verifies that the Acceptance Criteria has been met and that the Definition of Done is satisfied after the Sprint Review (Demo).

  5. This Product Owner gives the OK to close the story.

  6. The Scrum Master closes out the stories and the sprint.

  7. Scrum Master will create a new Sprint for Sprint Planning.



Restful API Documentation Format

  1. Swagger IO format will be used for all of ODE's Restful Interfaces.

User Guide Documentation Format

When editing the user guide, please make sure to follow the steps below to ensure that all sections are updated.

  1. Update the Version History table
  2. All configuration properties need to be specified in the table 1 located in section 6.6.3. If you need to highlight any config parameter in the feature sections, you may reference Table 1 but don’t duplicate the information. You’ll notice, Sandesh, that I moved the VSD properties to Table 1. Please double check to make sure everything is there and correct, particularly the default values and whether the parameter is required or not. If a parameter has a valid default value, it would not have to be required. Otherwise, it should be marked as a  required parameter. Also, all non-required parameters should be provided in application.properties with their default value but leave them commented out.
  3. Each new feature needs to have a subsection to identify Messages and Alerts. I added these subsections to your sections Please populate the table in sections 7.12.1 and 7.13.1 with any warning or error messages logged or alerts returned as part of the communication protocol (if any).


Process for Handling Code Defects

A bug is a defect in a feature that has already been accepted. Bugs should not be used to detail new features and functionality. Bugs are directly related to features that have already been delivered and provide no new user value, which is why they do not have points. Bugs may be difficult to estimate and could take 30 seconds or 30 days to resolve.

When a Bug is discovered the following steps shall be taken:

  1. Create a Bug issue that contains the following information:
    Title:  Short and descriptive 
    Description: Reference the story that produced the bug. Describe what should be happening and what is currently happening.
    Instructions: Outline the steps to reproduce it,            

  2. Make a comment in the story that produced the bug.
  3. Assign the issue to a developer to fix the bug.
  4. Scrum Master/Team can close out the Bug issue after they have been fixed.


Process for Handling a Spike

The purpose of a Spike is to gain knowledge necessary to better understand a requirement or reduce the risk of a technical approach. They are used in research, design, and prototyping, There are generally two types of Spikes, functional or technical.  Because they add no value to a sprint, they should be used sparingly.

When a Spike is deemed necessary, the following steps shall be taken:

  1. During the Product Backlog Refinement or Sprint Planning Ceremonies, it may be determined that a Spike is needed. The team will give their consensus and commit to the Spike for the upcoming Sprint.    .
  2. A Spike Issue will be created that references the story that triggered it.
  3. They Spike will be assigned to the developer with the most capacity or SME.
  4. The outcome of the Spike will be well documented (in the JIRA Comments as well as a separate document).
  5. Any proposed resultant stories will be placed into the backlog with label DRAFT, and including the ID (ie. ODE-###) of the Story that produced the Spike.
  6. The resultant stories will be discussed during the Sprint Demo.


Sprint Cadence

Once established, the Sprint Cadence should not be changed.  During Sprint Planning the Developers have the full autonomy to determine how they will complete the user stories.  If the team determines that a story can't be completed in one sprint, they should communicate this to the product owner.  The story should then be broken down by vertical slicing to produce the minimum functionality that can be demonstrated at the end of the Sprint.   The Story will be written up in phases to span multiple sprints.

Condition of Satisfaction

  1. Conduct the Research and meet with the appropriate entities to collect requirements to complete the feature.
  2. The objective of the story.has been met and stories have been identified.
  3. Product Owner has reviewed and accepted the story.





Enabler Story

Quality Enhancement

There are several types of enabler stories:  Refactoring,Testing, Technical Debt. They are used to increase the quality of the product.  In order to increase our testing code coverage, an enabler story has been added to Sprint 8.  This story will be assigned a 0 point value.  The enabler story will track the unit test added by subtasks.   Because it is 0 points, the enabler story can move to multiple sprints without affecting the scope of that sprint.

GitHub's Documentation Layout

  1. GitHub Read Me - Quick Start for Users
  2. Git Hub Documentation Folder - User Guide, Swagger IO links
  3. GitHub Wiki - QA test i.e Smoke test, User Acceptance Test, and Demonstration on how to use the ODE.