The purpose of a work management tool is to help teams of all types manage work, starting from capturing detail requirements, capturing bugs and issues, tracking them, and managing the test cases through Agile software development methodologies. With teams becoming global and adopting an iterative approach to developing software, the need for a single tool that is a central hub for coding, collaboration, testing, and release is critical.
With teams becoming global and adopting an iterative approach to developing software, the need for a single tool that is a central hub for coding, collaboration, testing, and release is critical.
The 13 project management tools for agile development:
How does a work management tool help the team manage the scope of work and structure?
The common goal of a project or product feature is to solve a problem, this is called the product initiative. Depending upon the number of epics associated with the product initiative. Depending upon the scope of work and the complexity of the work involved, an epic can take a few sprints to complete because it has a lot of stories associated with it. Remember an epic is a set of interrelated stories, or user stories that can stand alone as an independent body of work.
product initiative, a backstory, subtask, etc all have a clear owner
The stories are written from the perspective of an end-user with a clear set of detailed requirements that need to be developed and tested to mark the story as done. It is focused on narrating a single and simple job that user desires to be done, or a need that the user wants to have satisfied. The lowest level of work that needs to be done by the scrum team is captured as subtask.
Assigning Tasks
Tasks are assigned to development and QA team members depending upon the state of the ticket status.
Code review, assigned to a development team member
Verification phase, assigned to a QA person
User acceptance testing, assigned to a product owner (product manager)
In Kanban tickets, or scope of work, go through various states, from:
Ready for Dev
In Dev
Ready for Code Review
In Code Review
?
Ready for QA
In QA
Done
The visualisation of these states is helpful because it helps us understand the specific state of a ticket at any point in time.
These states are defined and managed by the engineering and QA entities in the organisation. The number of states and the type of state may vary based on the type of ticket, whether it is a story or an issue. The product manager needs to be aware of the states and their meanings, so they can understand the development process clearly.
In most cases, PMs (Product Owners) are required to conduct the user acceptance testing, after the QA team has completed the verification of a user story. When that happens, that product manager is required to interact with the ticket or scope of work, and update the ticket status.
Kanban States – Managing Work Flow
It starts by creating a ticket as OPEN, moving it from OPEN to IN PROGRESS and then moving it through CODE REVIEW to be verified and then moved to the state RESOLVED and then CLOSED because it has been verified by both the product manager and QA team.
In some cases where the ticket is open but no longer relevant, it is closed using the status as WON’T FIX.
Sometimes tickets are blocked in the middle of the sprint for a variety of reasons. It could be because the engineering team realised that this ticket requires another ticket to be completed first or additional information is required from the product manager or designer. So a ticket that started IN PROGRESS could move to the BLOCKED state by stopping the progress.
When the ticket is no longer BLOCKED, it’s move it to REOPEN state.
JIRA Product Management Tool
The more popular work management tool is called JIRA. Here’s a demo one:
The JIRA board has the backlog. There are only 8 issues, but there could be as many as 300 plus tickets. The tickets have a different icon; the blue one is a task (created by engineering team), the green one is a story, and the red one is a bug.
View the details of each item in the backlog which includes the User Story and the Acceptance Criteria.
Epics in JIRA
JIRA shows all the Epics. Remember the structure of the work where certain stories are associated with an epic. You can see how many User Stories are associated with each Epic.
Starting and Ending a Sprint
The product manager is not responsible for starting and ending a sprint. But this it what it would look like if you did.
There is something called as an active sprint, which usually shows all the work that is available in an active sprint – empty here.
In order to be able to start a sprint, tickets need to be moved (drag and drop) from the backlog to the sprint. In the product backlog, the top list of items are the most important tasks, stories, and issues that you want the development team to work on.
Now you can start the Sprint.
This creates a board that can be used by the Product Manager and the Scrum Team every day during the stand-up to review the tickets based on who’s working which ticket, and their names would be listed.
Tickets can be moved in and out of the Sprint but only if necessary, because the Sprints scope can be affected by this action.
