For information about the advice process as adopted by Cadence OneFive, see Handbook > Guidelines at Work > Horizontal Practices > Advice Process. Feel free to delete the blue call-out boxes in your final document.

Advice Process for

Sprint Visibility and Ticket Management

Original Proposer	Jeff Luna	Mar 21,2024
Revision Proposer
Revision Proposer

Advice Stakeholders (AS)	Consent Stakeholders (CS)
RobinChuck HenryJeremyLukeReuben?	Jason FrançoisBomee

Problem statement

I’ve noticed that our process for sprint visibility and ticket management seems a bit up in the air, or at least different from what I’m used to. It’s not a big deal, just means I need to put in some extra effort to get the hang of things (my bad!). But as we grow, wouldn’t it be awesome if we could make things easier for newbies? Let’s aim to streamline things and make on-boarding a breeze!

Summary of the challenges:

Monday:

There’s room for improvement in clarifying which tickets/PRs are included in the current release.
We’ve already taken steps to address this in the Sprint planning doc by,moving forward, linking items under the ‘This week’s Release’ section to their associated tickets/PRs so that will already help a ton.
The tickets and specifications for tasks requiring testing aren’t very visible, often requiring multiple clicks in Github to locate them within the associated PR. Typically, Github’s flow places code changes before the summary, meaning you’d need to delve into the ID to access the conversations tab, where the specification or ticket description hopefully resides.
I as someone who is new, are facing challenges in identifying PRs that have a significant impact on customers or are of high priority item.

Tuesday:

There’s currently no way to mark a ticket as ‘tested’ once the testing is complete.
We need to improve coordination among testers, particularly to avoid overlapping test efforts.
I’ve found myself spending time testing a feature that won’t be released that day, only to discover it already had known issues being addressed (and was behind a flag).

Goals

For Anyone who will be involved in the process to:

Enable everyone involved in the process to dedicate more time to testing rather than figuring out which tasks/tickets are ready for testing.
Utilize the tools already available to us, such as Zenhub or Github Projects, which we may already be investing in, to streamline our processes and workflow visibility across projects.
Implement a ticket status-driven approach and enhance the ticket life-cycle, with a focus on QA or test ownership.
Aim for increased coding time for developers, possibly resulting in shorter Tuesday meetings or utilizing the daily scrum as sufficient for updates and coordination.

Proposal

Ticket state driven Sprint, and Ticket management
Optimize the utilization of Zenhub by leveraging its Sprint Board feature:
Currently, the Sprint board in Zenhub appears cluttered and needs reassessment. Ideally, the board should display only the essential tasks for the current sprint, allowing for focused tracking of ticket movements.
Zenhub offers more flexibility compared to Github Projects and is reportedly more user-friendly for project managers, based on tutorials. (Although I personally haven’t used Zenhub - I’m more accustomed to Youtrack and have been managing with Jira.)
Or ultimately if we are not going to stick with Zenhub, are we open to exploring a different tool?

Proposed ticketing cadence(Some of this we’re already doing):

A project is being built which should be an epic in Zenhub by the owner
All the planning and documentations of collaborations will live in where it is right now- in Almanac
All agreed tasks to meet the feature specifications are individually ticketed as stories once the initial spec for a V0 is agreed upon
Tickets gets assigned to respective owners of the tasks
As we go towards the end of the project ,the Epic can only get closed when
All tickets (including bugs found along the way are closed and verified) no lingering open tickets
All Feature flags that are related to the project should be removed when consent stakeholders agreed that the project is ready for GA.
Epic closed

The sprint board should be reduced to only 6 columns showing the state of the tickets as the team work on them.

Proposed Sprint Ticket Life Cycle (QA Embedded):

Open/Reopened → Dev in progress → Ready for QA → In test → QA verified → Released to prod

Rationale: This process will provide both technical and non-technical stakeholders with visibility into the progress of each task or ticket.

Open: Indicates that the task is assigned but no work has been done on it yet.
Cod in progress: Indicates that someone is assigned and actively working on the task.
Ready for QA: Indicates that the code has been merged and is deployed to the staging environment. The owner is prepared to hand it over to QA, with the developer confident that the ticket won’t be reopened.
In test: Indicates that testing is currently underway, performed by the QA team or any other designated tester.
QA verified: Indicates that all specifications have been met satisfactorily and the ticket has been approved. The ticket has been reviewed from the customer’s perspective, and any additional issues or edge cases are documented for tracking or added to the backlog for prioritization.
Reopened: Indicates that the ticket has been reopened due to unmet requirements or issues. It remains in this state until the coder addresses the concerns and the ticket progresses back to the “Coder in progress” stage.
Released to prod or closed: This stage occurs only after the changes have been deployed to production. QA performs a post-release check to verify the changes, ensuring they are implemented correctly before planning for the next batch of tasks.

All unfinished tickets will move to the next sprint.
Separate Board for Unassigned Tickets: Establish a separate board for unassigned tickets, backlogs, low-hanging fruit, or SWAT list items. Avoid including them in the current sprint board to prevent confusion. (Reflects current state of Zenhub)
Differentiate Infrastructure/Groundwork/Data Pipeline Tickets: Distinguish between infrastructure/data pipeline tickets and product or customer-facing tickets. This differentiation aids in identifying the level of testing required and potential test owners.
This approach aids in prioritization by ensuring that testing efforts focus on items that directly impact end-users.

PROS:

Improved Monday meetings: Clear visibility of tickets in the sprint beforehand allows for more focused discussions and better preparation. (Everyone just looks at that board)
Live testing opportunities: Tickets marked as “Ready for QA” can be picked up by QA even before the testing day, enabling early issue detection and faster resolution.
Improved task prioritization: With tickets categorized into different states, team members can quickly identify which tasks are currently undergoing testing (“In test”) and allocate their efforts accordingly.
Increased accountability: The defined ticket states promote ownership among both developers and non-developers, potentially fostering a culture of responsibility and collaboration.
Enhanced estimation and communication: Utilizing Zenhub analytics, project managers can gain insights into team performance and project progress, leading to more informed decision-making and better communication with stakeholders and eventually, customers.
Comprehensive testing coverage: Clear ticket states facilitate tracking of testing progress, ensuring that all tickets are thoroughly tested before release and minimizing the risk of overlooked issues.
Advanced test planning: Improved visibility allows QA to plan and prioritize testing activities more effectively, enabling proactive testing for upcoming features and enhancements.

CONS:

Potential resistance to manual effort: Some engineers may be reluctant to invest additional effort in updating ticket states manually, preferring to consider their work complete once the PR is submitted.
Need for manual oversight: Until automation is implemented (between Zenhub and Github), ensuring tickets are correctly linked to PRs and updated to the appropriate state may require manual intervention, adding an extra layer of oversight.
Responsibility for automation research: Tasking the team, on researching and implementing automation between Github and Zenhub. .

Context and Background

Disclaimer: If this is just me being super early in the process, and I just need to know the lay of the land better- let me know, but if everyone think it’s a painpoint, I think we should address it as early as now.

During Release 55, I found myself fully immersed in the process for the first time, and I encountered several challenges.

On Monday, we kicked off the week with our stand-up meeting to review what was on the docket for the release. While there was a section in the document labeled “This week’s Release,” it was unclear which tickets or PRs were associated with it. Fortunately, moving forward this template will now include links to the relevant items.

In an attempt to gain clarity, I delved into the PRs on Github under the “Actions” tab. However, I encountered two “Fly Staging Deploy” workflows, and upon inspection, one seemed to contain months of updates unrelated to this week’s release. I focused my attention on the duplicate workflow instead.

Navigating through the PRs proved to be somewhat cumbersome. It took three clicks to reach the “Conversation” tab of a PR, and even more if there was a link from Sentry. This made it challenging to grasp the purpose of the PR, especially when it primarily consisted of a log that may have already been reviewed by the engineer.

Tuesday was designated as test session day. I appreciated the summarized PRs provided as part of the branch, which facilitated testing. However, I encountered difficulty in indicating that I had already reviewed a ticket and it no longer required attention.

I understand that the new add building modal will not be released due to its incompleteness and feedback regarding its usability in a separate thread. However, imagine approaching the situation from the perspective of someone who is unaware of this information. They would proceed to review the PRs as usual, potentially spending time on features that are not intended for release that day. Instead, it would be more efficient to set aside those PRs related to the hidden feature and focus solely on what’s actually scheduled for release to general availability (GA). This ensures that testing efforts are directed towards tasks that contribute to the immediate release cycle.

Reflecting on the PRs reviewed, I realized that only a handful were directly impactful to users out of the extensive list of commits. Additionally, there were instances where I found myself inadvertently duplicating testing efforts with others, highlighting the need for clearer communication and coordination during test sessions.

Ultimately, the goal is to streamline the testing process, allowing us to focus more on testing and less on navigating through the complexities of ticket management.

Next Steps

	Action	Meeting Date/Time
Discovery	Wait for everyone’s comment/ review of the doc - preferably till tomorrow or early next week.	N/A
Debate	I think we can just discuss within the doc, or a slack thread- but does everyone think a 5 minute turn taking debate is more beneficial to tackle it?	TBD
Decision	Francois and Jason are the only ones I could probably call as the Consent Stake holders whether this will be a good to try/experiment with. Once both approves: We probably need to time block going through Zenhub and Github and take advantage of how we could better integrate the two tools.Research how to map, automate the movement of the tickets in Zenhub, based on the PR state in Github. Decide what sprint / release # we will begin.	TBD

Post-Ratification Notes & Lessons Learned

Experiment Start Date
Progress Evaluation Date
Experiment End Date (if any)