21
Your problem is you've got too much granularity. Do you really need to know that this specific task will take this specific developer this specific number of minutes?
My question is... why?
Many modern Teams, aware of the inherent difficulties and inaccuracies of estimation, take up a less granular approach in order to make that inaccuracy (reality) more ...
20
Your problem is not that you have developers and non-developers (as you call the business analysis/product owner, the designer and the testers). Your problem is that these people have individual ownership on their slice of the cake and not on the entire cake.
Here are a few things from the Scrum Guide (emphasis mine):
Development Teams are cross-...
17
Your team appears to do mini-waterfall development within each sprint, which is a known anti-pattern, as you don't get the collaboration within the team that make agile methods successful.
Also, Scrum only has 3 "job titles": Product Owner, Scrum Master and member of the Development Team. There are no separate developers and testers, they are all equally ...
14
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 ...
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 but ...
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
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 ...
10
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 ...
10
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 ...
10
You are doing a lot of good things already, but I would also recommend the following:
Reduce how much you bring into each sprint
Keep on reducing it until the testing bottleneck disappears and the team completes all the work they allocate to a sprint
Continually reinforce the point that the team's job is to deliver completed items, not to do lots of coding.
...
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
Other comments here all ring true: too waterfall-y, not enough team responsibility, etc. but I'd like to emphasize a point made just once in other answers: you're absolutely setting goals too high. You HAVE to set bite-sized goals that are achievable, no matter how slow that is. If that doesn't fit the business schedule, the business schedule cannot be met ...
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
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, ...
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
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
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 one ...
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 ...
7
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 ...
7
Creating user stories is to get the conversation going and to give the team context to understand the problem at hand to create the correct solution. Also it forces the writer to think about the value it adds. Using something like INVEST makes sense here.
If the value of the technical tasks is clear I think using a user story format is just waste of time. ...
7
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 ...
7
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 ...
7
The direct answer to your question is that how you bill your time to the client is not addressed in Scrum. Therefor there is no billing model that is expressly anti-scrum. If adding a place on the board where you track time is the easiest way for your team to keep tabs on it, feel free.
Now, there are billing models that can incentivize anti-Scrum behaviors. ...
7
Trying to figure how project management can help my team complete tasks faster
Project management, and tools like JIRA, are (in the context of software development) ways of making your project move faster, and more reliably, by eliminating waste and sharing relevant knowledge. They also can be of assistance when estimating the time a certain part of the ...
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
