Hot answers tagged

5

TL;DR Yes. There is no issue with this at all. Discussion Points The concept of Epics are pretty amorphous and undefined. You can find descriptions of Epics as large user stories that need broken down and in that regard, it is common for some to try and squeeze them into a release train window. For instance an Epic may be a container for a specific ...


4

Unfortunately it seems like the exact problem you are having does not have an easy solution. The issue was reported back in 2012 on https://jira.atlassian.com/browse/JSWSERVER-6053 but the makers of Jira has set it in status "Gathering Interest" and seems to think the current behaviour is okay. Here are some workarounds you can try... You can turn ...


3

Most of your proposed workflow looks ok, but there is one thing that will bite you. The Test case issue type should also be associated with a workflow that moves from states New => Under Testing => Success/Failure No. A Testcase should have a workflow like New => Being Written => Ready for Execution. Next to that, you should use an additional ...


3

I also believe that the most concerning part is: the PM has decided that whilst the AC has been met, the code should not reach production as it does not deliver a suitable enough value to our user. I see three possibilities here. The PM does not believe that the AC need to include providing value. The PM is not putting in enough effort to the AC to ...


3

First and foremost, you can't use tools to solve this. If there is any problem here, it's a people problem and a communication problem. I say 'if' because this may be fine. Maybe it's something that really only effects them. Or maybe they are, after their 1-on-1, sharing the info with the right people. If you are seeing impacts where info isn't being shared ...


3

From Agile manifesto: Individuals and interactions over processes and tools Your objective is NOT to avoid communication. You want to promote it. People in a project must communicate in the most effective way they see fit. I believe you should shift the focus of your energy, changing the question you're looking for answers to questions such as How can we as ...


2

Jira is not a communication tool, but that doesn't mean you can't add information gained elsewhere to a ticket. If something is unclear in the ticket description, by all means ask around until you understand it, and then come back and update the ticket description. If your conversation unearths missing acceptance criteria or a link that would be relevant to ...


2

What we do in our projects is create separate Quick Filters with the Epic Link for each projects in the JIRA Board. So, individuals involved in a single project can filter out the tickets. Project Manager can overlook the whole program status by not selecting any specific filter which will ultimately show all the tickets on the board. Hope it helps.


2

Tiago's answer and Llewellyn's answer both give good perspectives on the overall approach. However, I'd take a slightly different approach. Since Jira tends to be more accessible than an individual's email inbox and private Slack channels or DMs, I tend to think of Jira as the source of truth and use integrations to allow people to push content into Jira ...


2

It depends. Who's going to look at your boards, and why? You should use Jira to meet your business needs and processes, not the other way around. So ask yourself and others: Do we need to track both? Is there anyone who cares about dev tasks but not management tasks? Is there anyone who cares about management tasks but not dev tasks? Is there anyone who ...


2

Short answer - yes, in your filter you will have items watched by other people so long you are also one of watchers. If you'd like to have a filter where you are the unique watcher, you'd need to also add an exclusion criteria stating that others are not watchers (which is cumbersome and not very effective). Now, bringing the question to the PM / leadership ...


2

Visualization ≠ Dependency Management Visualizing the work is a technique, and generally solves for a problem that this group of individuals may not actually have. To find value in a solution, you first have to determine what problem you're actually solving for. While I suspect the problem is dependency management, that's not self-evident from your original ...


2

"Allowed" by who/what? Allowed by Scrum? Yes. Scrum is a framework, entirely encompassed by the Scrum Guide. There is avast array of processes that Scrum does not prescribe, assuming/allowing/forcing individual Teams to figure them out for themselves. This is one of them. Allowed by Kanban? Yes. Kanban is even less prescriptive than Scrum. Kanban ...


1

There are no rules, so yes! But this is a question to ask your team(s). If they want to do so, go for it. If not, don't.


1

I have two pieces of advice for you. The first is that you need to balance two guiding principles: Start small and add on as needed, not vice versa. Your workflow should reflect your reality. I'm assuming you already have a pretty solid grasp on those, so I'll move on to my second piece of advice: Ask the team. While I know you didn't mention Scrum, its ...


1

I doubt that there is a technical solution to this problem. The underlying issue is in the product management space. The fact that the product manager is specifying what to build, having the team go out and build it, and then deciding that the wrong thing was built is extremely wasteful and costly. Rather than trying to figure out what to do with these ...


1

I'm not a big fan of Feature Toggles (because they can become a maintenance and configuration nightmare if not properly managed), but this could be a solution for deploying the code, without making it available to users. When the Product Manager (PM) eventually decides a feature can be shown to users, you just toggle the feature and later remove the feature ...


1

I surmise that what you're calling a "spontaneous task" is when a trouble-ticket is filed that has to be dealt with right away. These activities are separate from the project that you're roadmapping, and don't belong in it. But you do need to record and account for the time. You do need to know what percentage of your work-day is available for ...


1

As pointed out by other answers, a roadmap and making a plan are different in concept. In practice, however the two often mix. A roadmap is a big picture of your product strategy or direction. It lays out the things that need to come together to build an useful project and meet your goals. If you think about the roadmap as a plan, then it's the high level ...


1

As you say, your overall goal is to have an overview of the work being done, which would be visualized in the bigger time span, as opposed to our week to week work where we focus on smaller tasks at a time In that case... why not just have a catch-all 'Spontaneous' Epic to which you assign all such spontaneous Tasks? The reason why I wouldn't use a catch ...


1

There is a difference between a roadmap and planning. It seems to me that you try to plan all the work so that the PO knows when it is done and thus omit work to an epic eventhough it belongs there. That looks wrong to me. A roadmap, in my eyes, shows the priority of things you want to work on but has no deadlines. The team (to be clear: all roles in the ...


1

Jira is a grand tool, but also please check out the venerable Microsoft Project.® MS-Project is extremely good at helping you to break down projects into smaller pieces which have dependencies on each other. It is also very good at handling "separate" projects which have dependencies – which surely will be your company's case here. It's a ...


1

In my opinion, your colleague's suggestion is an excellent one. "'Stories' refer to what the user will eventually see – not the prestidigitation that will be required to finally let him see it! If it so happens that, in your "shop," the "stories" that are coming in can be usefully subdivided into classes – especially classes that ...


1

The proposal for adding sub-tasks to every user-story up front for each type of work involved in completing the user-story assumes a different way of working with sub-tasks than you are currently doing. Presumably, the person who made the proposal had in mind that the user-story would remain the PBI that gets estimated and planned. The sub-tasks would then ...


1

This is a fairly common approach taken by many teams. Often times the teams find it helpful to have those sub-tasks to organize their work. At the same time, it is not strictly necessary. Many teams do fine without them. The one trap to it is that you need to make sure that focus doesn't move so much to the sub-tasks that attention leaves the backlog items. ...


1

You can do that with issue types. Read more here on set up issue types in next-gen projects. By default, next-gen software projects come with the bug standard issue type which is used... ... to track problems with software, such as user interface discrepancies, broken functionality, or other niggles experience by users. To add bug issue types: From your ...


1

Meh ... Just go right ahead and define your "story," this being "your encapsulation of a hypothetical user's interaction with your proposed system." Absolutely define it – capture it – any way that seems best. After all, "this is a user story," and a user cannot be expected to know – or to particularly care – how a system ...


Only top voted, non community-wiki answers of a minimum length are eligible