Scenario - Feature Request

A New Feature request gets submitted by the Client.

A MISV stakeholder requires an update to MISV (DoC) or MISV-ADMIN

Typical questions include:

Can you add the ability for users to do 'x'?

Typical workflow for me:

Asking how urgent the requirement is -- is it impairing their ability to function, or is it a quality-of-life improvement?

Create PBI's and tasks, and sprint-plan accordingly

Scenario

<Client>

Client accesses the MyTC webportal [does not exist] and locates the “Submit Request” link. Client clicks the link. MS Form is launched that prompts the client with a number of questions regarding their request. The client indicates the request is for a new feature to the MyTC Platform Admin completes the details of what is required within the form and submits the form [generates a request].

<Client>

Receives confirmation of request via email that includes the DevOps ticket #

<Holly>

Receives email indicating a new request has been received that includes the DevOps ticket #

Holly clicks on the ticket # link within the email to open the DevOps Ticket. Holly can see who created the request and the pertinent details. It is obvious from the request type that this is a new feature being requested for myTC Account Admin.

Holly moves the state of the request from “New” to “In Planning” and Holly creates a discussion comment and includes @client email and indicates – “we will triage this request and reach out as soon as we have an assessment”. Holly saves the request update.

<Client>

Receives an email that Holly and team will triage the request. (Includes a link to the request)

<Holly>

Creates a task as a child of the request in devOps to host a triage session with the myTC Management team. Holly creates a meeting invite that contains a link the DevOps request# and sends the invite to the necessary myTC Account staff.

<myTC Account staff>

Receives a meeting invite with the DevOPs request#. Each member accepts the meeting. Each member [should] review the request details prior to the meeting.

<myTC Account Scrum Master>

Creates an initial Feature in the DevOPs development backlog and creates a discussion comment and includes @Holly email and indicate – “a place to capture further discuss”. Scrum Master saves the request update.

<Holly>

Hosts the triage session to discuss the request. [How is the request triaged, urgency? Impact? Risk?] Try to decide what to do with the request <Defer> <Needs Clarification> <Proceed>

<Holly>

Changes the status of the request to “On Hold” and creates a discussion comment and includes @client email and indicates – “This request does not align with our current priorities but will be placed on Hold and reassessed at a future date”. Holly saves the request update.

<Client>

Receives an email that the request will be put on hold

</Defer>

<Holly>

Creates a task as a child of the request in devOps to host a clarification session with the myTC Management team & the client. Holly creates a meeting invite that contains a link the DevOps request# and sends the invite to the necessary myTC Account staff & to the client.

<myTC staff>

Receives a meeting invite with the DevOPs request#. Each member accepts the meeting. Each member [should] review the request details prior to the meeting.

<Client>

Receives a meeting invite with the DevOPS request#

<Holly>

Hosts the clarification session to discuss the request. Any notes or clarification points are captured within the DevOPs request. [Can a decision be made at the meeting?] <Proceed><Closed – No further action>

Close the task for hosting a clarification.

</Needs Clarification>

<Holly>

Changes the status of the request to “Closed – No further action” and creates a discussion comment and includes @client email and indicates – “This request does not align with our mandate and is being rejected”. Holly saves the request update.

<Client>

Receives an email that the request will be closed – No further action

</Close – No further action>

<Holly>

Does the request require design? Move to <Design>

Define the necessary work items <Feature Definition>

<UX Staff>

Define the necessary research and design activities in the UX Backlog in DevOps. Inform Holly that work will begin.

<Holly>

Changes the status of the request to “In Progress” and creates a discussion comment and includes @client email and indicates – “This request has been moved to in progress and work will begin”. Holly saves the request update.

<Client>

Receives an email that the request is moved to in progress.

<UX Staff>

Create a devOPs task for a design review. Invite Holly, Client and myTC Account Technical Staff to design review

<Holly>

Receives an invite to attend a design review.

<Client>

Receives an invite to attend a design review.

<myTC Account Technical Staff>

Receives an invite to attend a design review.

<UX Staff>

Hosts the design review and registers any follow-up actions within the UX backlog. Close the devOPs task to host a design review.

<UX Staff>

Create a devOPs task for a design review. Invite Holly, Client and myTC Account Technical Staff to design review

<UX Staff>

Complete the necessary design tasks and mark them as done in the backlog.

</Design>

<myTC Account Scrum Master>

Create a task to “host a feature kickoff session” under the already created feature within the DevOPs dev backlog.

Schedule a feature kickoff session with dev team leads, UX (as required) and Holly.

Create a new feature in the DevOPs Dev Backlog. Breakdown the feature into associated high level PBI’s.

<UX>

Receives invite to attend feature kickoff

<myTC staff>

Receives invite to attend feature kickoff

<Holly>

Receives invite to attend feature kickoff

<myTC Account Scrum Master>

Host the feature kickoff session. Review the feature and PBI’s and with the assistance of the team attending the session define the needed acceptance criteria for each PBI to ensure the feature is “ready” if it is prioritized for the sprint. Mark the task “host feature kick-off session” as completed.

The feature and PBI are now considered “Ready” and be part of a sprint planning.

[Note: Any feature or PBI’s not considered “Ready” can be brought into the Sprint planning process but at greater risk, it should be known that the PBI’s are considered incomplete and may require greater effort to work on them so estimates should be set according to the risk.]

</Feature Definition>

<myTC Account Scrum Master>

Send invite for a sprint planning session.

<myTC Account Scrum Master>

Schedules a sprint planning session and invites Holly, Pat and all myTC Account Staff

<myTC Account Staff & Holly & Pat>

Receives an invitation to sprint planning

<myTC Account Scrum Master>

Host the sprint planning session. During the session it is decided the request is a priority and it is assigned to a staff member.

Who is the “right” person to take on this issue? Assign the PBI/Task to the appropriate myTC Dev Staff.

<myTC Account Dev Staff>

Receives an email that a PBI/Task has been assigned to them.

<myTC Account Dev Staff>

Works on the PBI/Task work and corresponds with the client directly (if required). Closes the PBI/Task when the work is completed and includes @myTC Account Scrum Master in the comments

<myTC Account Scrum Master>

Receives the email that the PBI/Task has been completed.

<myTC Account Scrum Master>

Schedules a sprint review at the completion of the sprint and invites Pat, Holly, Team and the client to attend.

<Holly>

Receives the email invite for the sprint review.

<Client>

Receives the email invite for the sprint review.

<myTC Account Scrum Master>

Hosts the sprint review to show-case all work completed during the sprint.

The client get a demo of any work performed related to their feature request.

</Proceed>

New Feature Scenario

Scenario - Feature Request

Scenario