Geekly Articles each Day
📜 ⬆️ ⬇️

How to set up task types and not go crazy

Prologue

In a previous post, I wrote how to organize the process of “grooming” tasks in the JIra system so that the “Product Manager” would be comfortable navigating through the entire Backlog of the product. Continuing the grocery topic I will write about how long I have been going to understand what types of tasks in Jira are.

It is important here to say that further the structure that I will offer is suitable for the process of product development (s), but it is unlikely to be correct for project management. By the way, if you are concerned about the question of why Agile is more a product management framework, but read about it here .

Task structure

In the Jira system at the project level, there are three levels of tasks: Epics, Stories / Tasks, Sub-task . Original article here . Jira allows you to customize these entities quite strongly - you can change the names, pictures, customize your workflow for these tasks. In this lies the root of evil! The more you “customize” the system to your needs without having a consistent understanding of what is what, the more it raises questions and ultimately rejects from working in this application.

Observations

Having experience in several organizations, I watched as all participants in the process who are working on a product try to understand and agree on what they will understand by Epics, Stories / Tasks, Sub-task. I must say that this is a fierce dispute, because no one wants to change the existing order in their team or product. It would seem, and so everything is clear, what is there to discuss? Epics is a big task, Stories / Tasks are smaller tasks, Sub-tasks are very small and not mandatory entities. But it seems so only at first glance.
')
The difference in understanding is due to the fact that some develop a product for a specific piece customer, other teams simply “saw the boxed product” for thousands of customers. For the first Epics, this is a large and concrete refinement from the client, which they will break into smaller Stories / Tasks. For the second case, this is a kind of great Wishlist that came up with Product Owner, while it is not clear how time-consuming this Epics will be. There is a third option that was invented in the depths of the company - Epics is the “delivery” of software increment in a certain period of time.

Such a different understanding of these “three birches” is caused by a different finite interest. It is important for the project manager to understand when the developers will do the tasks that they have been assigned, it is important for the product manager to see and understand the product map, the final performers do not want anything at all (the development team is already tired of change by this time).

What to do?

The solution to this problem is. Returning to the beginning of the article, I’ll say once again that Agile is well suited to automate the process of product development, and not project activities (or at least you need not to mix these two concepts into one).

That is why we must say our decisive “fi” to everyone who tries to lobby for everything that is not related to the principles customary for the Product Approach.

We develop a common understanding

So, what do we mean by these types of tasks given the fact that we agreed on the fact that we adhere to the product approach to the development of the system.

For a long time I tried to grope this view, tried on different schemes, tested the settings on users, the most viable scheme was this:


All UML lovers will immediately understand everything, but for those to whom these three letters do not speak about anything, I will explain further what's what. By the way, after I laid out all this understanding in my head, I came across this article of my namesake.

What is the precedent in the system? It is also often drawn in the form of a “use case diagram”, which is essentially the same thing. Very often when it comes to use cases, for some reason, the work of an online store always leads, and I will not be an exception.

We will have an online store selling books. Well, let's go!
Case
“The user on the site for the sale of books wants to purchase goods. Before that, he has already registered and authenticated. ”


Epics . This case describes a use case in which, as shown in the picture, there are several actors and many different actions. By Epics, we will understand a specific precedent in the system . This is quite convenient since the entire system can be divided into precedents and thus group smaller tasks. I suggest that I call Epic - “Purchase of goods on the store's website”.

Story . Since it is impossible to evaluate and even less plan large tasks (they definitely don’t fit into the sprint), you need to learn how to decompose them. So let's break down our use case (Epic) into smaller user stories. And we know the rules for forming a good user story:


Looking at the picture, we can easily break the whole precedent into “parts”. Let's call our stories like this:

  1. “As a buyer, I want to be able to order a product.”
  2. “As a buyer, I want to be able to choose a payment method.”
  3. “As a buyer, I want to be able to search for a product.”
  4. “As a site operator, I want to be able to monitor and maintain customer data”
  5. etc.

Thus, we can beautifully arrange this type of task, and at the same time observe all the rules.
Sub-task . We still have one more type of task that is worth considering. Although in flexible methodologies there is no such thing as a “requirement”, the client’s wishes are sometimes quite accurate. I suggest not to lose such clarifications of the client or product specialist and record them as Sub-task. Let's return to our “rams” i. the buyer of books on the site. As I propose to split the user story into requirements:

  1. “As a buyer, I want to be able to order a product, and the order button for the product must be blue.”
  2. “As a buyer, I want to be able to order the goods, and the order button should be called“ To cart ”and be 100x150 in size.
  3. etc.

In our case, if there are specific functional and non-functional requirements, we create sub-tasks in the system under specific user histories. By the way, one Sub-task should not exceed on labor intensity more than 1.2 days.

What is the result?

In this post, I proposed the principle of forming task types for teams that are working on creating a product in such a way that everyone will be satisfied.
The product manager analyzes the needs of the market and creates Epic, details them with the development team on user stories. The master scrum monitors the sprint's saturation with stories and facilitates rallies and retrospectives. The development team thinks through ways to implement the stories and decomposes the User story into a Sub-task.

Instruments

For the Product Manager there are excellent plugins such as: Structure for Jira , Easy Agile User Story Maps for Jira , Pivor Report . In them you can see the structure of the tasks and not get lost.

For the Scrum Master, consider planning tools for poker. Although I personally use applications on a mobile device to display scorecards. You should also not forget on the Burndown chart and monitor the blocking.

And the development team should look at the Kanban-board of an active sprint and put flags on tasks if something went wrong.

I hope that this article slightly shed light on this seemingly simple question - “what will we mean by Epics, Stories / Tasks, Sub-task”! In the next review, we will consider how to satisfy PM, if we are not a product team, but a project team.

Source: https://habr.com/ru/post/447082/

More articles:


All Articles