how to show velocity without entire page ready? - component based website architecture

[Jordan_C_Walsh@homedepot.com]

JIRA + Scrum/sprints - How to scope this story for velocity?

story: migrating an entire page to a new platform, one component at a time. cannot release to Prod without the rest of the components.

Question: which "status" (aka, In-Progress, End-to-End-testing, Done, etc.) should we use for the status of "Component on the page is Done and validated by QE in LLC Environments (Dev and Stage)... but we cannot release it to Beta/Prod until all components on the page are finished" ?

With all component stories for the same page in one epic... current process is leaving the story in "Pending Deployment" until the entire epic of stories is done, which shows zero velocity for the team.

Other Solutions?

[Bill Sheboy · Accepted solution]

Hi Jordan_C_Walsh@homedepot.com -- Welcome to the Atlassian Community!

Some approaches to meet your use case depend on:

1. what problem you are trying to solve by having velocity for unreleased work,
2. who releases features to production, and
3. what capabilities does your team have for releasing to production? 

Starting backwards with #3, if your team is able to release "disabled" or with feature toggles, you could just release completed work and enable it later, or on a schedule.  So work is completed when it is released.  Enabling it later could be a different work item, as is measuring its delivered value in production.  Teams using automated CI or CI/CD pipelines may build this flow into their tool usage.

Next with #2, if another team is releasing to production, your team could discuss what is in your "definition of done", and perhaps it ends prior to release.  In such cases, release uses separate work items and possibly change management tools.

Finally with #1...what problem are you solving with velocity for those items? 

From a generic scrum perspective, completed work leads to a "potentially releasable product increment".  Some teams update that to include "released".  If you need velocity to forecast progress against an epic, that is one thing.  If instead your stakeholders want forecasts that include "in production; in customers hands", that is another thing. 

Some might say "done" for only means in-production-and-in-customers-hands.  Your team's needs and choices can help you decide how to manage work to effectively deliver value to your stakeholders.

Kind regards,
Bill

[Jordan_C_Walsh@homedepot.com]

Thanks for the answer and the welcome @Bill Sheboy!

I believe our team has the ability to release to production without taking traffic. So technically I could validate with a set of canary/prerelease version url parameters, and our QE & PDM would be validating each component in a "Prod-like environment". In that case it would be validated in a "releasable state" although they would obviously not release it until the final piece of the puzzle is delivered.

I believe this is the best approach for everyone involved in a component based architecture platform that needs to work on new/re-vamped pages one piece at a time. So I will called this one answered!

Respectfully,
Jordan

[Trudy Claspill]

@Bill Sheboy's answer is a better, more complete answer than mine. Way to go!

[Trudy Claspill]

If you want to get velocity credit for work, the story has to get transitioned to the final status displayed on your board.

If the definitions you have set for the statuses in your workflow are such that your stories are not considered complete until the change is deployed to Beta/Prod, then it seems like your stories would be stuck and your velocity would be zero.

An alternate solution is to not have Statuses reflecting the different stages of the change. Instead have a generalized "Done" status, and define what that means in each story. For instance, you could have a story where the Definition of Done is only about completing the code change, and having separate stories that track the work of testing that change, and deploying that change to Beta/Prod.

[Jordan_C_Walsh@homedepot.com]

Thanks for the idea! I have worked on a team in the past that separated out the "task of deployment to beta/prod" since there are usually multiple changes to validate for each Prod deployment. I think Product Management usually wants to call it done after it is available to the customer. So maybe this is just a redefining the teams "definition of done".