My job profile allows me to interact with clients and their development partners almost all the time, which gives me an opportunity to understand varied projects, their progress and blockers too.
One of the most common problems I observed with the delay of the project is - unstructured and non-standard detailing of the Drupal tasks in Jira.
This issue of non-structured details is often caused by the problems with the very generic kind of Epic-Stories-Subtasks structure in Jira. This almost makes the developers handicapped by impacting their ability to deliver on time.
Worst part of this entire mess is - they don't know where exactly they are making the mistakes and where they should actually fix the same.
Let’s take a simple example of a Product feature covering the provision of adding new products to the website.
- Epic detailing is just for example purposes - ideally it should contain more elaboration and details.
- The UX + UI part is already done so I am not including relevant stories in this example.
- Testing activity is taken care of in the parallel sprint so those stories are not covered in this example.
Necessary information we can expect from BA
- There needs to be a content type called Product
- There needs to be a category so products can be differentiated.
- Products should be displayed in a multiple displays - Detailed Page, Grid and List
- Catalog for each product needs to be pulled through an API (exposed from the legacy application)
So far so clear…
How this information gets into the Jira is a big question. Business Analysts may prefer to add this entire information in an Epic or an individual Story. So the detailing part is well done.
Here onwards how this detailing will be taken care of in the Drupal implementation and how that is distributed in the form of Site Building, Backend, Frontend and API Integration is the important part. Unless and until this is distributed well it becomes very difficult to track the individual ownerships.
Though it looks like a long list, it is surely not a time consuming job.
What we just did?
- It’s a simple Epic to Stories (and spread through the Sub-Tasks under each story) structure.
- Any business specifications are included in the Epic.
- Entire functionality is split into smaller and measurable chunks in the form of stories with a clear differentiation of SIB ( Site Building), FED (Front-end Development) and BED(Back-end Development).
- Each story is also labeled with the relevant keywords so it gets easier to filter the tasks easily.
- This differentiation helps in terms of distributing the ownerships and analyzing what kind of resource expertise is required to complete the implementation.
- Each owner of the story can further create the further detailing in the form of sub-tasks, for example for CW-2 story and its relevant sub-tasks.
Creation of Sub-tasks
What we just did?
- Developers can translate the business mentioned in the Epic description in the form of Drupal deliverables.
- This helps in terms of estimating the smaller sub-tasks more efficiently.
- Such minute level detailing will help developers in terms of coming up with any kind queries and blockers much in advance.
Benefits at Project Delivery level
- More realistic visibility in terms of resource utilization, time estimate and complexity is available to all stakeholders.
- Developers will be very much in control of the implementation activity.
- It gets much easier for the SM or PM to analyze where exactly the implementation part of the project is headed for.
- Last but not least every aspect of the implementation gets measurable.