- Q: How does an example ticket to work on look like?
- Q: How do we estimate work?
- Q: How are tickets selected for work?
- Q: What is the lifecycle of a ticket?
- Q: What is the structure of the team?
- Q: What are the tools used for work?
- Q: How would my calendar look like?
Q: How does an example ticket to work on look like?
Normally ticket that is marked "Ready for Dev" and is available for the developer to start work on has the following information:
- A description that gives us a context and background of the feature that needs to be implemented or the issue we need to fix
- Acceptance Criteria that define what should be done
- Tech notes uncovering technical details
- Estimate in Story points
- Sprint, Epic, and other common attributes
Description
Example of ticket
As a traveler, I want to see if a tax is included in the room’s price so that I can be more informed about my hotel reservation.
Acceptance criteria:
- Given a hotel returns room rates with $0 taxes for 1 night, then when the user hovers over the nightly rate, the window should appear with the details of the nightly rate and say that taxes and fees are “Included”
- Given a hotel returns room rates with $0 taxes for multiple nights, then when the user hovers over the nightly rate, a window should appear with the details of the rate and say that taxes and fees are “Included”
- Given a hotel returns room rates with a value for taxes for 1 night, then when the user hovers over the nightly rate, a window should appear with the details of the rate and the actual value of the taxes and fees.
- Given a hotel returns room rates with a value for taxes for multiple nights, then when a user hovers over the nightly rate, a window should appear with the details of the rate and the actual value of the taxes and fees.
Q: How do we estimate work?
Work is estimated on 2 levels of fidelity:
- High-level T-Shirt sizing estimate for Roadmap-level work, where:
- XS - less than a sprint of work for a team
- S - 1 sprint
- M - 2 sprints
- L - 3 sprints
- XL - 5 sprints
- ... and so on
- Story Points estimates for individual tickets, i.e. tasks. We use the Fibonacci sequence where 1 point means 1/2 day of work including development, QA and product review. Example estimates:
- 1 point - 1/2 day of work
- 2 points - 1 day of work
- 3 points - 1.5 days of work
- ... and so on
Q: How are tickets selected for work?
Product Owners and Engineering Managers work hard to prioritize tickets in a sprint and backlog. They place them in a specific order because one ticket blocks another, a team needs to do some critical investigation or resolve an important issue.
Developers need to take tickets to work in the same order as they appear on the board, from top to bottom, one by one. All "Ready for Development" tickets are unassigned on the board in the "To Do" column. When a developer needs to take a ticket, he should go to the board, take the first ticket from the top of the "To Do" column, assign it to himself, and change the ticket status to "In Development".
Q: What is the lifecycle of a ticket?
When a new ticket is created, filled in with all the details and needed information, it gets placed into the backlog and waits for the backlog grooming session to be groomed and, maybe, to be pulled into a future sprint. Before the session, devs take tickets to check its feasibility, find a possible solution, and prepare an estimate. Once a ticket was groomed, received an estimate, and was filled in with all needed details, such as tech and QA notes, we move the ticket to the "TO DO" status and can pull into a sprint. After that, the ticket’s lifecycle is pretty common for scrum teams:
- Picking up for development
- In Development
- Code review
- Testing
- Product Owner approval
We heavily rely on automated acceptance tests that are a part of our CI pipeline. So we can deploy to production at any time. The only constraint is a green pipeline and passed pre-release smoke testing.
Q: What is the structure of the team?
We work within vertical and self-sufficient delivery teams.
The team consists of:
- Tech Lead
- Product Manager
- 3-5 Developers
- 1-2 QA Engineers (we strive for a 1-to-3 ratio between Dev and QA)
- Scrum Master
Q: What are the tools used for work?
- For Messaging - Slack
- For Calls - Zoom
- For task tracking - JIRA
- For knowledge - Confluence
Q: How would my calendar look like?
We have an amazing process in place that gives you both the flexibility and support you need to do your best work:
📹 Monday and Thursday - Video Daily stand-up (15 mins)
🎙Tuesday and Wednesday - Daily stand-up (15 mins).
❌ Friday - "no meetings" day
🔶 Once a week - Backlog grooming (1 hour).
🔶 Once a sprint - Sprint Review (30 mins).
🔶 Once a sprint - Sprint Planning (30 mins).
🔶 Once a sprint - Retrospective (1 hour)
📅 Here's an example calendar of a typical week at the end of the sprint
We use retrospective as part of the “continuous improvement” process. Also we sometimes use time on Retrospective to play fun games to learn more about each other. For example - “share your dream vacation”, “your 3 favorite YouTube channels”, “weird Instagram accounts you follow”.