14
I can feel the frustration in your post. As someone who made the transition from a PMO to an Agile role I can understand both sides of the coin.
Your question has multiple components which I will take in turn but all of them have effective communication at their core.
Why are management more interested in logging hours?
This could be a number of things ...
14
Jira links are broadly used, as far as I can see, for an information-only purpose.
All in all, it boils down to how your team uses it.
With that in mind, it'll strongly depend on what is considered a "dependency" and a "blocker" in your context.
Given the following scenario:
foo depends on bar
foo is blocked by baz
One way of reading it is as:
...
13
TL;DR
Newly-discovered bugs and defects are new work. As such, they must be made visible and move through the standard Scrum processes.
Analysis and Recommendations
If there is a defect which [maybe] connected to a previously closed ticket, we create a new one. However, we had a discussion on adding the possibility to reopen a ticket.
If you knew about ...
12
I would focus on the need, rather than the implementation. The user story would then simply be:
"As a user, I want any personal information I give (Company) to remain private and secure."
With HTTPS then being an implementation detail of that story. After all, if you found some other means of completing the requirement (such as not getting any personal ...
9
Is it possible to add a person to watch an exising issue, without assigning the task to him/her?
Absolutely, this is documented within Watching and Voting on an Issue:
If you have the correct permissions (see below), you can also
view the voter and watcher lists for an issue and, you can manage the
watcher list — that is, add other people to the ...
9
First of all, you are potentially misusing user stories as a mechanism. A user story emerges from a real need, it should not be invented or changed to fit the process.
Anyway, it could be something like:
As chief security manager, I want all communication between all our applications and all clients to be done via HTTPs so that the risk of a MITM attack ...
9
An epic is a large story. One that needs to be broken down into stories that fit comfortably within sprints. It isn't really meant to be used as a way of grouping stories together in a category.
Having said that, do what is best for your team. If you find grouping technical debt tasks under an epic helps you to track them, then that is fine.
My preferred ...
8
Why is management is more concerned of JIRA burndown chart than of following Scrum values in project development?
3 common reasons for this type of behavior are:
Lack of trust
Poor understanding of Agile methodologies; still thinking in waterfall terms
Delivery Team is not meeting commitments
Why do some members of the team not like to log hours in JIRA ...
8
You're starting in a quite common environment. 6 people in production, no quality assurance people, several concurrent projects. And, let me guess, you've got ASAP requests pretty much every day.
Here's what you should do first:
Sort out your development (new features) and suport (bugs, changes) projects.
Now separate your production team across ...
8
In JIRA boards are simply views on projects. It is the projects that contain the stories, epics and other issue types.
This means that you can create a new board that points at an existing project.
Say for example your original Kanban board was called 'Team X'. When that was created it would have created a project called 'Team X' as well. The board would ...
8
TL;DR
You have an X/Y problem created by skipping over analysis of the process problem in favor of a tools-based approach. JIRA and GitHub Issues are tools, not processes, so until you fully define your process flow you will remain at disadvantage.
You need to define what you are tracking, why you are tracking it, and how you will use the tracking data to ...
7
You should take a look at Jira Issue Collector. An excerpt from its docs:
Need to capture feedback on your website or web application? Want to make it easy for end users to directly create bugs so your developers can act on them?
If you develop web-applications or web sites, the JIRA Issue Collector is the best way to turn your customers' and users' ...
7
It looks like you should configure Estimation and Tracking for your board.
Jira can track progress in either story points or hours:
If you select Time Tracking "None" then issues will burn down their Story Points value upon completion.
If you select "Remaining Estimate and Time Spent" the Burndown Chart will be based on "Remaining Estimate" and "Time ...
7
To make it easier to log hours in Jira you can use the worklog assistant program. The worklog assistant grabs all filters from Jira, you get a list of the current sprint issues for example. It warns you when not logging time. Its possible to publish automatically or do it manually and correct some logging when needed. Create some place holder tickets for ...
7
There are two kinds of bugs found during a sprint:
Bugs resulting from current, on-going development work
Bugs found during the sprint but from work that was done previously
The usual Scrum practice is to prioritise bugs found that were caused by on-going development work. These bugs will be added to the Sprint Backlog as they are blocking stories from ...
7
Each board has a filter, the filter contains the order. By default this is rank, because you pick lower ranked tasks later they get dropped at the bottom of the done column.
You are looking to update your filter to something like:
project = TST ORDER BY resolutiondate DESC, rank ASC
This way if the issue is finish it gets ordered on its resolution date, ...
7
+1000 on Daniel's post: Do not use task hours at all.
Hour estimating is something you'll find a lot of the leading agile experts recommend. And then look that the time stamps. I'm not aware of any leading agile voice that still supports hour tracking of tasks. It's been deemed counter-productive to relativistic estimating of story points. The goal of ...
6
Lead by Example or hire a consultant
In my previous company, we in the the software development team switched over to the agile development process. Over a period of time the following benefits became visible to the larger organization:
Vertical slices of work were delivered to end users frequently. We were demoing completed features every two weeks and ...
6
If developers can't remember the tasks they're working on, then this could be a symptom of two possible problems:
1. There is too much WIP
that there is too much WIP (work in progress) occurring at any given time. Agile methodologies like scrum encourage teams to focus on getting things to the done state as quickly as possible, and working on more than ...
6
The reason Scrum teams often use story points for estimating is that it provides an effective way to calculate the capacity of a team. They also allow for lightweight forecasting when doing release planning.
The reasons they use time-based estimates on tasks is different. It is so that they can:
Spend time breaking work down, which often helps when it ...
6
There is a lot you can do that ensures that the code does what it's supposed to do, but aside from trusting the people developing it (including their reviewers) there is basically no way to make sure it does not do more.
But it comes down to that trust in any other job, too. At some level, you need to trust the people. If you cannot, get others that you ...
6
Using a Behaviour Driven Development (BDD) or Acceptance Test Driven Development (ATDD) approach means that the code is self documenting. So introducing functionality beyond the original requirements would be obvious to anyone who paid attention to the code base.
What constitutes 'extra code' is a much more difficult question. It is quite possible that code ...
6
Option A should just not be done; don't do any invisible work. If new work crops up in any form, document it. This is assuming it's not just a two-minute thing, of course, but if so then it's probably not worth talking about in the first place.
As for what should be done...
While working on that story, s/he runs into an issue that could or could not be ...
6
No, splitting technical tasks off into new stories is not the answer. The idea behind delivering a "potentially releasable product increment" is that the stakeholders can say at the end of a sprint: "We like this. Let's put this in a beta test among selected customers." or even "Let's move the release date forward and beat our competition."
When they say ...
6
Outside of the Jira context, an Epic represents some kind of deliverable business value. An Epic is usually made up of good Stories, the full value is realized to the client and users after all of the stories are completed and delivered. Not all Stories need to be part of an Epic. I would also say that other types of backlog items, such as items that ...
6
There is some grey area here, but let's start with a clear answer to work from. Epics are a derived idea from User Stories - specifically an epic is just a big user story that you've broken down into smaller stories, so to address what you're asking it makes sense to walk through the breakdown of the user stories (and therefor, epics). I don't know your ...
5
We do this the other way around:
Requirements are handled in confluence (the wiki part of the atlassian suite).
In Jira, for each requirement, one or more Epics/Userstories are created, but only for the next 2 or 3 milestone releases.
Back linking from jira into confluence is done with a simple HTML link (confluence does autolinking if you cut and paste a ...
5
If you are doing Scrum you do not need to record this time.
This is not really a Jira question, but one about Velocity and how you allocate resources to a Scrum team.
Scrum advises that you allocate team members fully to a given project. Of course, every team member has other duties and distractions. But Scrum assumes that amount of other work would be the ...
5
The closest you can get to this, as far as I know, is:
Epic
|
+--Story
|
+--Sub-Task
To accomplish this, define your Epics and give them each an "Epic Name". Then define your Stories, and within each one select the appropriate Epic within "Epic Link". From each Story, as needed, create any Sub-Tasks.
To give an example, if I were defining ...
5
How do we manage small tasks and big ideas in the same list?
In Jira Agile you can create epics to represent large stories. When you decompose this epic you can write several stories with the same epic as the parent. For smaller tasks, you can create sub-tasks under a story.
...manage one large website and a group of minisites/mobile apps.
In the above ...
Only top voted, non community-wiki answers of a minimum length are eligible
