How to track your Product progress?
This is part 6 of a long-form series of setting up your Product Stack’s Project Management correctly.
You can read Part 5 about the different Product building methodologies and the basic framework on which methodology to employ according to your organizational needs here.
If you’ve already set up your Project Management Boards, feel free to skip to the next part where I discuss how to plan your sprint in case of a Scrum methodology of development.
So, we’ve set up our Project Management, deployed our Issue Types, and decided on their stages. The last part where it all comes together is to start creating issues on Project Management and mapping these issues on Project Boards for tracking building progress across.
We finally get to the part of building your Boards for managing the progress of your Product-building efforts.
In part 4, we discussed the usual construct of your Project Management depending upon the types of projects you might have. Quickly recapping here, we finalized the following Boards to be created to exhaustively track each issue type covered in the last part -
- EasyRide Consumer Development Board
- EasyRide Consumer Design Board
- EasyRide Agent Development Board
- EasyRide Agent Design Board
- EasyRide Driver Development Board
- EasyRide Driver Design Board
- EasyRide Engineering Scrum Board/Kanban Board
- EasyRide Design Scrum Board/Kanban Board
In part 5, we also discussed the two most commonly used Prodict building methodologies Scrum and Kanban. We discussed a handy framework for deciding which methodology to prefer.
Please note that out of all the types of Projects discussed above, you need not have a specific Board for the ‘Initiative’ Project type since you’d not be tracking Initiative Issue types on any Project Boards but mostly on plans since they’d be super parents to all Issue types.
Here’s a brief link to learn about the creation of a Project Management Board on Jira.
Let’s discuss your Board implementation concerning both methodologies —
Scrum
In the Scrum type of Product development, the type of boards that you may have would depend on your Scrum structure. Here’s a link about the creation of a Scrum type of Project Management Board on Jira. The number and types of boards you’d need would depend further on the type of Scrum team division you have -
Single Scrum Delivery Division
In the case of a single scrum team where your entire delivery team is just one single team of engineers and designers, you’d need one Sprint Board each for Engineering and Design efforts tracking. Thus, you’d create two projects as discussed in part 5 for Engineering and Design, and a Scrum board on each Project. This project should refer to all your ‘Product’ type Projects in terms of ‘Issues’ that’d be available on this ‘Project’ as the source.
You could have other Project Boards set up for each Function in the organization but that wouldn’t add value since you wouldn’t be building on any requirements by dividing them into Function-wise trackers. Please note that you should still create Function-wise Projects and have your Issues initialized into Projects only. You just wouldn’t have any additional value added by tracking any development requirement on likewise boards.
Please note that you would usually have a single scrum delivery team to start with until you come up with a neat division structure for your PODs.
The following would be the boards in each Project that you should have in this division type —
- EasyRide Engineering Scrum Board
- EasyRide Design Scrum Board
Product Oriented Delivery Division
If you have a POD type of organization where you have a Scrum team each for a Product or for some combined Products, and have a different sprint planning and delivery process for each POD, then you should have a Board for each Scrum.
If your Design Team is also structured into PODs and functions as differentiated teams, then you should have two Boards for each Function-type Project that you have created. Otherwise, you could have a single Design Scrum Board and multiple Engineering Scrum Boards for each Function type Project.
In any case, you should have an Engineering and Design Scrum Board that references all other Function type Projects for Issues and would give the total wholistic Product building effort picture in one single place across multiple Sprints of multiple Scrums.
The following would be the boards in each Project that you should have in this division type —
- EasyRide Consumer Development Board
- EasyRide Consumer Design Board
- EasyRide Agent Development Board
- EasyRide Agent Design Board
- EasyRide Driver Development Board
- EasyRide Driver Design Board
- EasyRide Engineering Scrum Board
- EasyRide Design Scrum Board
Kanban
In the Kanban type of Product development, the type of boards that you have would be one each for Engineering and Design since there would not be any further division in either of your teams even if you have internally structured your teams into PODs.
The following would be the boards in each Project that you should have in this division type —
- EasyRide Engineering Kanban Board
- EasyRide Design Kanban Board
Product Board
In addition to all the boards mentioned above, you could have an all Product Board which would list all the Epic Issue Types assigned to various Associate Product Managers or Product Managers in your organization. This would give you visibility of how much deliverable work has been assigned to any Product Manager-type personnel in your team. There’d only be one board for this type of Project —
- EasyRide Product Board
Please note that this board should be Kanban type since there’d be no relevance of a Sprint/Scrum at a Product level. The concept of breaking down deliverables according to sprint would start at a level below the Epic level.
Issue Stages
The structure of all the Boards in your Project Management tool is such that there are vertical lanes of Issue stages in each Board that represent Issue Types in each stage. This is exactly what gives a visual representation of all your Product-building efforts’ current progress.
For configuring which Issue Types would be displayed on any Board, you could refer to this link here.
Following should be the Issue Stages for each of your Project Board Types -
Design Scrum/Kanban Project Board
For the Design Scrum/Kanban Project, the following Issue Types would become the ‘Source’ Issue Types to be displayed in the Source Filter of the Board -
- Design User Story
- Copy Writing
- Usability Testing
- User Research
For each Design Scrum/Kanban Project Board, the following should be the Stages that should be configured to be displayed according to each Issue Type -
In the diagram, we can observe that all Issue Types would form a part of the same board, and for all the columns configured. I’ve also highlighted each Issue Type’s specific stage that would be mapped to the Board’s Column/Stage.
For Example — This diagram indicates that a Design User Story would be displayed in the column called ‘Design In Progress’ when its status is ‘Design In Progress’ while at the same a Copy Writing task would be displayed in the same column when its status is ‘Work In Progress’.
This would help in giving a real-time picture of all Issue Types currently under work in a Sprint or a Kanban manner specifically from a Design and Content perspective only.
Accumulating all the above knowledge, this is how your Scrum board would like for your Design Sprint —
From the board, we can observe the following —
- Design Boards in their Scrum or Kanban format should quickly give you the gist of all deliverable Epics that are being developed or worked on right now
- You should be able to drill down into any Epic and quickly get a current snapshot of each ‘Design User Story’, ‘Copy Writing’, ‘User Research’, and ‘Usability Testing’ up for development in an Epic, their current status, and their estimated time for completion
Both the above points would enable you to track any of your deliverables at any point in time quickly and conduct a cadence call every morning.
Engineering Scrum/Kanban Project Board
For the Engineering Scrum/Kanban Project, the following Issue Types would become the ‘Source’ Issue Types to be displayed in the Source Filter of the Board -
- Development User Story
- Bug
- Task
For each Engineering Scrum/Kanban Project Board, the following should be the Stages that should be configured to be displayed according to each Issue Type -
In the diagram above, we can see that most of the columns of a Development Board type of a Board would be more or less the same.
Accumulating all the above knowledge, this is how your Scrum board would like for your Engineering Sprint —
From the board, we can observe the following —
- Engineering Boards in their Scrum or Kanban format should quickly give you the gist of all deliverable Epics that are being developed or worked upon right now
- You should be able to drill down into any Epic and quickly get a current snapshot of each ‘Development Story’, ‘Bug’, and ‘Task’ up for development in an Epic, their current status, and their estimated time for completion
Both the above points would enable you to track any of your deliverables at any point in time quickly and conduct a cadence call every morning.
Product Project Board
For the Product Project Board, the following Issue Types would become ‘Source’ Issue Types to be displayed in the source filter of the board —
- Development User Story
- User Research
For each Product Project Board, the following should be the Stages that should be configured to be displayed according to each Issue Type -
Notice that the diagram actually encapsulates stages from both Feature and Epic Issue Type which should have a parent-child relationship. Hence, the initial stages of the Board would have Features mapped while the latter stages would have Epics mapped.
There’s a neater way of arranging this Board by arranging the swimlanes of the board to be ‘By Assignee’ such that for specific Assignees the only Issue Types assigned would be Features (Senior Product Manager/Product Manager) and for some others, the only Issue Types assigned would be Epics (Product Managers/Associate Product Managers).
Thus, your Product Board should look like this —
From the board, we can observe the following —
- Product Boards should exist in the Kanban format only since at the Product level, the deliverables haven’t yet been broken down into user stories and other tasks
- You should be quickly able to get the number of Features or Epics assigned to your Product Management team members by looking at the Product Board and their current status
- Your columns of the Product Board should be a mix of the statuses in your Feature and Epic Issue Types
Board Swimlanes
Board Swimlanes are the rows to be displayed to introduce a grouping mechanism for all Issue Types included in a board.
For customizing the grouping mechanisms for your Board, refer to this link here.
Following should be the swimlane criteria for your Boards -
Epic Swimlanes
Grouping swimlanes by Epic would give you the visibility of a stream of work’s all related issues to be displayed in the same row and thus, would give you the exact visibility and the exact status of each Issue.
This should be your most preferred method of grouping together Issues on a board. If you have to take a Scrum standup meeting turn by turn, you should filter by assignee from top of the board, to move according to which person’s turn it is to report the progress. It’d help you gain the exact visibility by assignee as well as by Epic.
Assignee Swimlanes
Grouping swimlanes by Assignee gives you the visibility of a stream of work related to one personnel all at the same place. This helps you if you’re addressing a smaller unit of the team and should be used when one Epic is divided in such a manner that multiple scrum teams happen to work on one Epic. In such a case, grouping together by Assignee or personnel would give you more visibility to track progress and attend meetings.
Summary
The total number of Boards that you’d have as trackers for your Product progress would depend upon the type of division you have in your Product Team. It’d also depend upon the number of personnel and division of work amongst your Product teams.
We’ve listed all the Projects, Project Boards, Board columns, and Board Rows so far taking the example of the sample Product Application that we started with.
In the next part, we’d discuss the unit of estimation to be taken to plan across Products and conduct your Sprint Planning.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
