Specification 2.0
What do we NOT want
What do we want?
Actions
Tickets
Tickets with ambiguity
Tickets with no use cases (As a user I want to...) (aka user story)
Tickets without Acceptance Criteria
Scope change or acceptance criteria in the comments only (i.e. not also part of the task description)
Big tickets that are actually Epics
KPIs without measurability (e.g. "we need server to be faster" --> how much faster?) be specific
Tickets without prioritization
Tickets that contain scope that is beyond the limitation of our tech stack - i.e. our tech cannot even deliver this ⚠
tickets without mockups or visual interpretation where applicable
Tickets that are one-liners (i.e. one line tickets)
Tickets that would take forever to be completed - scope is too big to implement in 1 sprint
to have to make assumptions about systems that I do not know, i.e. I do not want to have to guess how the tech works on my own as a PM
a Ticket goes into implementation that has never been through any form of of grooming/review
links to a lot of different projects/tickets without summary of what was previously implemented and only link to other tickets
Missing any requirements when specifying a feature/project etc. ⚠
Misunderstanding what the functionality needs to deliver
super old Tickets created by people who are no longer in the company and we need to figure out what was meant by them
parallel communication with stakeholders by different people who are working on the same project which creates confusion & different requirements
Devs asking requirements from non-tech stakeholders or trying to explain requirements without PM presence ⚠
reopen or update done/archived tickets if there is a need to continue working on the same context of the archived/done ticket
Having too many endless discussions and asking permission to speak with Devs of other teams regarding scope
No updates of the tickets outside the ticket itself
Related tickets not linked
discussions about tickets that happen outside the ticket are not written/summarized in the ticket (as a comment or in the description)
No structured body of tickets, just plain description
Ticket done/completed/live but not made public to stakeholders relevant for it
specification review cycle to take >2 weeks ⚠ ⏲
create endless documents to explain the scope needed to be done (i.e. create 5 different documents just to explain the scope of the functionality)
Specification Process that fills up my day with tons of meetings
Bugs?
What are the exceptions?
AB tests
small bugs OK?
big bugs no?
Share AB test results and choice of option is enough grooming?
killing AB tests?
It's enough to mention in the daily that a variant of AB test should be rolled out ✅
hotfixes?
hotfixes already demand everyone's attention
they are groomed by default in our daily discussion
what to do with very big scopes?
breakdown the scope into smaller chunks when specifying things
coordination Tech lead