Only issues which are in the last column on your board will be considered done by the Scrum board. And therefore any ticket not in the last column may not count towards burn up/down reports.
Tickets waiting for review/QA may linger around for long and due to bottlenecks and aren’t completed by the Sprint closing time.
Are QA and PR review being considered when a task is estimated? Common trend: QA bottlenecks towards the end of the Sprint.
Infra requirements - e.g. setup new clusters, procurement of services, etc - may lead to delays and therefore they must be brought up to the attention of a key stakeholder as early as possible before they become a blocker.
The team should open 2-3 Sprints (i.e. current + 2 future ones) on Jira and start filling them up based on the business goals/product team's delivery expectations.
There should always be enough room in those open Sprints for work that spills over from ongoing Sprints and new injections from the backlog.
Unsigned tickets MUST NOT be included in those open Sprints. Unsigned = lack of ownership = lack of grooming = poor delivery and general dissatisfaction.
Tickets whose solutions or requirements are unclear or missing at the time of estimation MUST NOT be included in the Sprint.
Effort estimation has its benefits for teams working on mostly standard tasks and when teams have similar skill sets. However, they can be highly subjective as far as units of measure go.
In comes estimation by ideal day:
-
0.5 point (half-day): Any ticket that might take the assignee from a few minutes to a whole morning/afternoon. Always a same-day delivery. These are normally used when a change of context is required in order to deliver the ticket - e.g. it takes time (context-switching costs) to spin up new VMs just so that a single line of code can be changed..
-
1 point (1 day): any ticket that might take the assignee more than a morning/afternoon and can still be completed within around 24 hours. The assignee can start working on it one day and deliver it by the next day.
-
3 points (1-3 days): These tickets will definitely take more than a day because of their complexity or dependencies on research/familiarisation with the topic. But will be delivered within 3 days at most. Unexpected issues and blockers related to this sort of tickets MUST be brought up to Team Lead/Manager/PM ASAP in order to avoid delays cascading down to the next tickets.
-
5 points (3-5 days): These tickets are massive and will most likely take 3-5 days to be completed. Before we commit to a five-pointer, we MUST try our best to break it down into smaller tickets which can be estimated and tackled within a smaller time frame. However, if it's NOT possible to split the five-pointer, then it MUST be reviewed to include at least a checklist highlighting most of the steps required to complete the task at hand.
-
The team should try their best to avoid five-pointers, by splitting them into smaller more manageable tickets.
-
No more than a single five-pointer should be included in any given Sprint, regardless of the team's capacity.
-
Any team member who commits to a five-pointer cannot commit to a three-pointer in the same Sprint.
-
No one should commit to five-pointers in consecutive Sprints.
-
No one should commit to more than two three-pointers in the same Sprint
-
Managers note: review all non-dev work estimated at 3 or above because they may point to a skills gap.
-
Managers note: watch out for an excessive number of half-pointers. Possible root causes, but not limited to:
-
Ticket spilled over from previous Sprints almost done just missing very minor work, may end up in future Sprints with 0.5 estimation
-
Too many unplanned work / favours
-
The success of the team depends on your individual contribution. If you are overrunning with a ticket, DO speak up and be honest. That won’t get you reprimanded. But if you don’t speak up and you are found to be constantly overpromising and under delivering, then we have a problem.
-
Where are they coming from?
-
Do we need a gatekeeper in place until a habit is developed? (Key contributor vs Net disruptor)
-
Feature creep/technical debt
-
Stable/Done is better than perfect.
-
Dealing with interruptions: training and building awareness regarding Urgent vs Important
-
Always kickoff the Sprint planning meetings by asking who's out (on leave/vacation) during the Sprint.
-
New tickets will be assigned to the manager, which in turn will assign to an engineer/QA/frontender.
-
It's the responsibility of the assignee to familiarise themselves with the ticket's requirements ahead of the Sprint start.
-
Anyone creating tickets without the full context MUST assign the ticket to themselves until they have had the chance to provide context.
-
It's the responsibility of the assignee to familiarise themselves with tickets well before the ticket is estimated.
-
It's the responsibility of the assignee to chase requirements and bring up blockers to the Team lead/manager as early as possible. Use the ticket's comments section to chase requirements. And raise blockers over Slack/team calls.
-
Note to engineers: all tickets that require QAíng MUST include at least a list of steps highlighting how to reproduce/run/use the solution. Those MUST be provided to the QA team before the ticket is assigned to them.
-
Treat EPICS as themes under which stories/tasks are gathered. An EPIC type of ticket makes it easier to box up work and report on long running developments. But not longer than a quarter (or a month, depending on how Goals/OKRs are time boxed).
-
If a story’s estimation is too big, then break it down and split the story into smaller tasks and use Jira’s ticket linking feature to associate those stories.
-
Stories/tasks SHOULD be small enough to fit within a Sprint. Bearing in mind that there will be the odd story that outlives the current Sprint and end up included in the next Sprints, but that should be managed and reviewed.
-
You MUST NOT use Jira subtasks. If a story/task can be associated with a checklist then do so and for each completed item in the list use the comment section to communicate that that step is completed.
Cons of using Jira subtasks:
-
Lack visibility: not listed in the backlog, not listed under free search (unless advanced filters are used)
-
Not included in Jira’s default reports
-
No estimations
-
No time tracking