Technical Articles
Best way to create JIRA Task for Developers
Whenever a sprint starts there will be a planning/grooming meeting and this meeting is the most important meeting of a Development sprint for Developers. You must not miss this at any cost. Now coming to the question – Once the sprint planning/grooming meeting is over, the goal is that every developer should understand what we need to develop in the current sprint. In case of any doubts, you must clarify with the Product Owner or Architect. After proper understanding of work to be done, we need to create sub-tasks to each backlog which was explained in the planning/grooming meeting. While creating tasks we need to break them in such a way that each task should look like a logical subblock of development. Our Development lifecycle looks like this
Design -> Coding -> Unit Testing -> Writing Unit Automation -> Code Review -> Issues/errors resolution -> Documenting -> Release to Quality system.
Our task should also represent this lifecycle, but make sure to name them properly. Example – Coding task should not be named as Coding, it should be relevant to what thing we are working on. Let’s say I am building CDS Views for creating Production Allocation Results. My tasks should look like – Interface CDS Views Development – Prodn. Allocation Results, another task should be Authorization for Interface CDS Views, so on. Tasks should be named properly so that you at any given point of time understand them better and explain it to others. Also, use the Comments section in JIRA tasks to communicate with each other and also keep on adding whatever you have developed at the end of the day. Make sure that work like if you need to take leave urgently then work should not be stopped, another developer can understand from tasks and start from there.
Please share your thoughts to it
It is funny how different team setups and sizes impacts how Jira is used. On our case, we are relatively a small team with full control (and responsibility) of the release process.
My personal preference is to have the story holding what is relevant to get that value done, functionally and technically (when needed). And then our definition of done holds all the process bits we find mandatory (implemented, reviewed, tests green, documentation up to date...). And our status kind of are the check points for it (Integration, QA, Ready for Live).
There are a lot of flavors to Jira, I think that is why it is so easy to adopt, there is no one way fits them all so it allows teams to use it how they currently see best.
My only real concern about tasks is that they remind me too much of Work Breakdown Structures (WBS). I even saw it used as such, with %completion and all. It was really never up to date and it was painful to keep track, and they even looked like statuses sometimes (Integration Testing,PAC Testing...). And there were management reports on it, kind of missing the whole point around agile...
Thanks for sharing your way!
Cheers!
Awesome Felipe, this gives an understanding of how different team adopts to JIRA, I think that Tasks for a Developer should be in such a way that s/he understands it better at any given point of time.
Yes - it is interesting. I'm from a small shop.
If we need to do a large project complete with Jira. It tends to get a break down like this
And yes, the developer is needed in each of these steps. Less in some places and more in others. So I agree it totally depends on the project, the size, and the size of your shop.
If I could have one wish granted, it would be that the scope didn't change. Or if it did change then all dates moved. Including development and testing. Just one little wish....
So true Michelle,
Your last sentence is I think everybody's point of concern and I don't know if Agile Methodology also tells that if scope is increased then we need to adjust deadlines 🙂
Also, my aim is that JIRA should be used in a manner that a Developer should feel its usage not only managers 🙂
We use JIRA with many customized workflows starting with user requests all the way through to sign-offs when the work is done. User departments, IT and controlling are actively involved. Inbetween we have tasks tackled by the process teams collected under (at least) one epic for each user request. This then has different tasks and issue types dependent on the type of work needed and where in the process we are. The process teams usually work with one task for the effort estimation and another task for the implementation. If ABAP or forms development is needed a separate issue is created for that and it "lives longer" and has all the required status options needed to see development through from inception to go-live:
In the areas I'm involved with most, the development tasks are not cut down into smaller parts - unless multiple objects and/or developers are involved when sub-tasks might be created. The main reason for doing it like this - and I lobbied for that! - was to keep all information relevant for development in one issue and to avoid having to look through multiple items and/or replicate information from one to the other.
We rely on communication about an issue via JIRA-notifications and work a lot with @mentions.
Cheers
Bärbel
Thanks Barbel for sharing your thoughts and I too believe that all communication should happen through JIRA comments section for that issue as it gives a transparency and breaking the silos 🙂