My approach after managing projects with Scrum, Kanban, Scrumban
I have managed several projects in different ways (Scrum, Kanban, Scrumban, etc.), and this is the way I gravitate most of the time. I decided to create this article as a reference for myself, but also because I believe it could be helpful for someone.
This is what works for me, but I also adapt it to the reality of each team and project. It’s mostly a Kanban, but many times I change it to something else, maintaining the basic principles.
I normally use Jira to manage the status of all projects, including all the flow from creation to release of a ticket. It allows for the visualization of a Roadmap, work in progress, and releases of products. Not a huge fan of it, but gets the job done.
Customer Support Projects
Customer Support receives all the requests for support on a Customer Support project. This project can be separated by department on a bigger company (For example, Operations, Development, Sales, etc.) or by-product if the team manages several projects.
They should be filtered by Customer Support. If the request is a feature request, it should be moved to a Product Owner board. If the request is a bug report and it is clear what is the project, it should be moved to the backlog/board of that project.
Note: Customer Support can also create new tickets and link them if they want to keep the ticket on the Customer Support board. This is useful when we need to update a client on the status of a request.
Product Owner Projects
The Product Owner can have one or several boards where the Epis and Stories are written and prepared, while being discussed with business. The Development Manager can be asked for advice or estimations. Once they are ready to be developed, they should be moved to the backlog of the development project they belong to, and prioritized.
A development project can be a software product, or it can be a part of a software product. This depends mostly on the size of the team and of the product.
When the tickets move to the backlog of a development project, they have to be analyzed by the Development Manager. The Development Manager should consult the team whenever necessary, and give a rough estimation as well as a technical approach whenever possible. Estimation of tickets in a poker fashion with the whole project team is my recommended way of doing it. I especially like T-Shirt sizing, but Fibonacci is quite popular.
It’s important that we define what do we mean when something is done. I like to separate the definition of done into separate stages: Grooming, Development, and Testing.
- The story has a clear description of business value from a user’s perspective, written in a BDD style.
- The story is prioritized correctly.
- The story has all specific requirements listed.
- The story has clear Acceptance Criteria.
- Requirements are implemented according to the specification.
- Coding guidelines are met.
- Unit and Integration tests are done with greater than 80% coverage.
- Existing tests pass.
- Acceptance criteria are met.
- Code has been reviewed and approved by at least 2 peers.
- Necessary documentation was created.
- The product owner validates and approves the solution.
- QA team test and approved the solution.
Each project has its own backlog of tickets, although I do not use a backlog on Customer Support normally projects.
All tickets are created on the backlog and ordered by priority according to the Product point of view. This is managed by the Product Owner. The top 20 tickets should be described as completely as possible, and ready to be added to the To-Do column on the Board.
The Product Owner can also bring tickets that have been built and worked on other projects. These are tickets that come from Customer Support or from the Product Owner projects.
The board is different depending on the type of project. For both Customer Support and Product Owner projects, I normally only use 3 columns: To Do, In Progress, and Done. For development projects, the columns I use are: To Do, In Progress, Ready for Review, Ready for PO, Ready for QA and Done
This is just a starting framework. I many times remove or add columns depending on what works for the team and the project. Flexibility is key.
Tickets selected by the Product Owner to be done next. They should fulfill the criteria of Definition of Done for the grooming stage. They can be assigned to a specific developer, but normally are not.
The Product Owner may select tickets for To Do at the beginning of each Sprint, if we are doing Sprints, or just make sure that the team always has enough tickets to work on if pure Kanban.
If there are no tickets, developers pick the top one on the backlog.
The developer should pick up a ticket from the To-Do stage whenever available. If there are no tickets, or the developer has not the skills to do the ones that are there (for example, a developer is a frontend, and there are only backend tasks), then the developer should pick up a ticket from the top of the Backlog.
Tickets picked by the Developers that are currently being worked on go on the In Progress column. They have to be assigned to the person that is working on it.
Whenever a ticket is blocked for some reason, we:
- Flag the ticket.
- Add a comment describing the reason for the block.
- Add @ name tags for the person that needs to act.
- Mention it in the daily meetings if nothing was done.
Ready for Review
Tickets where the development has finished, and a Pull Request has been created for it. It remains assigned to the developer that worked on it. They must fulfill the criteria of Definition of Done for the Development stage.
Ready for PO
Tickets, where the Pull Request has been approved, are moved to this stage by the developer that worked on it, and assigned to the Product Owner.
If the Product Owner does not approve it, it goes back to In Progress, and is assigned to the developer that worked on it.
Ready for QA
Tickets that have been approved by the Product Owner and are ready to be tested are moved here. They are no longer assigned when they reach this stage but are picked and assigned by a tester when they start to be tested.
If the tester finds bugs on it, it goes back to In Progress and is assigned to the developer that worked on it. The bug has to be clearly described by the tester. A comment or a sub-task can be used for that.
Tickets tested and ready for release. They must fulfill the criteria of the Definition of Done for the Done stage. It is nice here to assign it to the developer that worked on it, but it can also be unassigned.
This is what Done Done means.
The Releases functionality on Jira should be used to organize what goes into each release. A Release with the correct version number must be created with the correct tickets linked to it.
A release environment is then created, and it is used for all the release tests by both the testers and the Product Owner.
Once the release is set, any further work needed for that release must be done using the release branch as the main branch.
When all tests have finished and the go-ahead is given by the Product Owner, the release on production is prepared with the operations team and the release notes are extracted from Jira.
Every ticket should be developed on a separate branch, taken from the master.
Only when a ticket fulfills the complete Definition of Done, can it be merged back to master through a Pull Request.
I like to keep it simple with the types that already come as standard on Jira.
Epics are created by the Product Owner and describe a general need of the user. Several stories and tasks may be added to an Epic. It allows visualization of the bigger targets on the Jira Roadmap.
Stories are created by the Product Owner and describe a specific user goal that helps to fulfill an Epic. A story must be sized in a way that it takes a maximum of a week to accomplish by 1 to 3 developers.
Tasks are created by the Developers and describe any task that does not come from a User need or request. This includes code cleaning, refactoring, general improvements, system administration tasks, setup of tools or environments, etc.
Sub-tasks are created by the Developers when needed. They can be used to split a Story / Task in smaller logical parts, or parts done by different people (Design, Backend, Frontend, Operations, etc.).
Bugs can be created by anyone that has access to Jira or to any bug reporting tool we use. They can be used to report any problem that may be found on our products.
It is important to be clear about priorities on a team. Most of the problems I have encountered in the past is when priorities on tickets are not correctly defined, or change all the time. Create a criterion that works for you and stick with it.
Stories and Tasks
Stories and Tasks are considered to have medium priority. Other priorities can be given to them, but the highest priority should be reserved only for bugs.
They should be done in the order set by the Product Owner on the board To Do column or on the Backlog.
For the bugs, we have to be more careful about priorities because there is a tendency to make them the highest priority. This is how I recommend to give them the right priorities.
- Severity: Seriously blocks users on a primary function.
- Criteria: Causes crashes, or endangers the whole system in general; potential data loss; Serious security problem.
- Release priority: A hotfix release must be created immediately with the fix. A developer stops what he/she is doing to fix it.
- Severity: Affects most users but they can still use the system in general.
- Criteria: Has the potential to block some users.
- Release priority: Must be included in the next release, goes immediately to the board. Whenever a developer is free, a high bug has bigger priority than any story or task on the board.
- Severity: Affects some users.
- Criteria: Has the potential to affect progress.
- Release priority: Can be moved to the board but has equal priority to any Story or Task. Can be prioritized by the Product Owner on the backlog.
- Severity: Minor problem with an easy work-around.
- Criteria: Missing translation; missing minor functionality.
- Release priority: To be prioritized by the PO on the backlog.
- Severity: Trivial problem that does not affect user.
- Criteria: Visual problem that does not affect functionality; Type on text.
- Release priority: To be prioritized by the Product Owner on the backlog.
I do not believe in one size fits all solutions. I adapt these processes to each team and project, but I believe this is a good start. With small modifications, this has worked for me and many of the teams I have led.
Feel free to comment with what you would add, remove and do differently. I am looking forward to learning more.