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
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
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 ...
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
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
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
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
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
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
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 ...
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 ...
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
You can assign the Epic's user stories to different sprints according to your needs. And when you browse the Epic you can see how its issues are distributed. Like the below example.
Only top voted, non community-wiki answers of a minimum length are eligible
