That depends entirely on how you are recording risk factors and what you want to see in your management reporting.
There's a lot of variation in what I've seen in a lot of client sites, but it really does start with asking the managers "what do you want?".
I want to see a list of projects and get a good visual of if a project is at risk of not being completed on time (Version release date target).
Also, if I have a set of n requirements, I would like to know if the tasks for those n requirements along with the test plans for those n requirements have been completed or will be completed or are at risk of not being completed on time.
Standard stuff guys. I can't believe we have to recreate the wheel over and over and over. But, I would love to know about the variations you have seen. Can you describe them (briefly)?
Mmm, a lot of it depends on how you're recording it. If, for example, you're using time tracking and estimates, it's a doddle to get out "we expect to get this much progress done", but you might be doing it with the Agile plugins, or you're only using parts of it.
When looking at requirements, are you doing them as stories? Main tasks with subtasks? The RMsis requirements plugin is quite good for a couple of my clients, but you need to think how you're estimating/planning those too.
It's not so much a case of re-inventing anything, it's more the case of what you're currently doing (whether it's in Jira already or you want to map existing human process into Jira) and how to make Jira fit your needs.
Actually, it is not standard stuff since Jira allows you to do things in multiple ways.
You can use a gnatt chart, but someone needs to setup the relationships between the tasks. Are these tasks issues, sub-issues, hierarchical structure of issues?
How are your requirements defined in Jira?
Are your engineers reporting their times correctly? Have you accounted for their overhead in your estimations or not? Have you built in checkpoints to verify the engineer's progress?
Are you using the 'Agile' approach? Are you using the peer programming approach? Are you using a different approach?
How and what your numbers mean changes based upon the data model?
You don't need to recreate the wheel, but we need to know which type of wheel and its structure (wheels spokes can have different number and style) to give you a better definition.
In my opinion, EazyBI is not meant for the end user to design their own reports, but for engineers to design their reports for end users to use. Its data model is quite powerful as long as you have good data to work with.
You would not expect your management to actually build the workflow, but they would use it and provide input for the workflow.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG