When using a tool like JIRA to curate your project management processes it is important to use it effectively. It is very easy to move off of the “happy” path and into the weeds that cycle a project into chaos. I want to touch on a few of the pitfalls and also highlight a couple of creative ways to use it.
Pitfalls
#1 Death by Ambiguity
When putting your work into any issue tracker it is always tempting to create items that are not only unhelpful but ultimately damaging to your project. If you are early in a project and dividing large chunks of work for future definition, items like “Email Notifications” or “User Profile Page” are not good for the project. Items like this feel good at the time, a list of them covers the breadth of the project, but they will hurt even in the short term. How can a developer know where to start with these? They span major components of an application, UI, server, client, and more. In many teams the same developers will not even work on these different components of the software.
Later in the project these can be damaging as well. For example, a few months down the road a developer is now taking on responsibility for the administrative screens in your shiny new application. They keep noting the need to work on email notifications but do not know where to start. The naming of this ambiguous item gives them the false sense of security that it is noted and will be handled, when nothing is further from the truth. Preliminary design work may desperately need to be done for the notifications to be ready in a future chunk of work (milestone, sprint, release), yet nothing moves. Developers that do not have the responsibility for other parts of the system touched by the item cannot, on their own, break it up into pieces.
Some forethought and design need to be taken early in a project to avoid these problems. Use a standard that works well for your organization. Break it up into meaningful chunks that will match up with your development team structure. For example we might enter the item as a part of other related work tied to the client, server, administrative screen design. This way the feature heads into the design process without cluttering and confusing future waves of work. Another solution is to specifically identify a design item for the feature. This is valid work and is worthy of being tracked as a part of most projects.
#2 Death by Stagnation
Another major pitfall is not breaking up larger items that are well defined. A large irritant to a customer (internal or external, there is always a customer) is seeing the same item stagnant and not moving for months. We try to keep most of our items at a size that can be completed in a week. This way the customer can see progress on a continuous basis. This often means that a particular item might be broken down into many parts, yet there is often resistance to this extra work. Not breaking up these components can leave your progress hidden from your customer.
All customers want to know when their shiny new application will be finished. This is a normal desire and one we challenge constantly in the custom software world. We all know we cannot control outside factors that impact or drive a customer’s business. In the course of a project, stresses and pressures will often come and your customer may begin to scrutinize the project in a different way. The game changed and you are still moving along. When the customer comes to look, will you have 20 large items moving slowly or 150 moving quickly through your process? I would much rather have a large number of items being clicked off weekly. The customer can see steady (sometimes daily) movement. They can predict themselves when the application might be completed.
#3 Death by Silence
Any system is only as good as the information flowing through it. The natural human tendency (especially for developers) is to only communicate when it seems important. Just like your marriage, your project needs good strong communication to be healthy. This seems so obvious, but I have watched this kill projects time and time again in my career.
JIRA specifically is a platform that is well suited to capture the story of a feature or item as it goes through its life-cycle. If used properly, you can come back years later to make a change and be up to speed in a few minutes. On some projects we have design, workflow, commits, and technical discussion going back ten years. Our detailed data predates most of the employees at the customer, providing a historical perspective that adds yet another layer of value.
Capturing this data takes a culture that requires effort to build and diligence to maintain. Ask each developer to comment on their progress on a regular basis, establish some guidelines. Have Project Leads check this as a regular part of their work process, build a culture of positive accountability. Find places to establish checks and balances that will protect these guidelines and give you the confidence they are occurring.
Outside the box
While just avoiding the issues identified above will make your project better, we have found a couple of creative things that are quite beneficial when working with our customers.
#1 Screenshots/Video
Media is powerful. We have recently started looking for screenshots on any resolved issue that is customer-facing. Having these available paid dividends immediately. Pictures are not only worth a thousand words, but more importantly they apply clear context to all the words you did write. Many of your customers are visual learners, use this to your advantage. Providing a screenshot or demonstration video beats a live demo every time.
#2 Feature based agile board
A quick and easy way to make a customer understand you value their priorities is a custom filter and agile board in JIRA. Simply add a label or a component, customize a filter, and create a board. Nothing will please decision makers more than seeing their high priority item flow through to completion. Giving that visual on the board can also eliminate those challenging schedule questions. They can see for themselves and begin to approximate completion. Do not underestimate the value of that last sentence. Giving customers the ability to answer their own questions quickly is powerful.
Conclusion
While not comprehensive, these ideas and concepts should help many who use JIRA or are considering the product. Staying on the good path takes effort but will pay off in improved communication with your team and your customer.
One thought on “Using JIRA: Be a Winner not a Loser!”
Comments are closed.