A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

Hot answers tagged

47

We resolve such issues as 'Obsolete'. This is not a default resolution option in JIRA but it is easy enough to add.


26

Nuances like that matter if you consider issue tracker as a means to communicate the status of problems that were reported in the project. For that purpose, it makes sense to invest some effort into ensuring that bug report is easy to read and understand. This situation gets much less confusing if you look at it from a perspective of a tester. If your team ...


12

Non-functional requirements come in many forms, but they have one thing in common: The don't describe functional behavior of the system but rather put constraints on the design choices that you can make. Non-functional requirements are ill suited to be expressed as user stories because user stories work best when they can be implemented once in a short ...


11

The issue might also lie in a too rigid separation of task between back-end and front-end development. If a front-end developer need a new API, isn't it possible to allow him or her to create a dummy API on the back end (returning always the same value for example) to validate the layout ? Then commit that partial implementation with a stub, and in a ...


10

If at the end of your sprints often you have many big tickets that are 90% - 95% done then there is something wrong: Red flag #1: Lots of things get packed into a sprint but are not finished Red flag #2: You have many big tickets Red flag #3: For some reason this affects the "last" 10% of progress Let's adress those things first: 1: If you repeatedly have ...


9

JIRA (and I'm sure other bug trackers) allows you to specify custom resolutions so you should be able to set up a "Overtaken By Events" or "Irrelavant" resolution, or similar to allow you to express the closure how you want Does it matter? that depends, for us I'd say yes as our customer is overly concerned about the number of open issues in our tracker, so ...


7

Assuming Kanban (as I think the answer is less relevant for a Scrum process), the lanes that you should use depend on organizational concerns, and perhaps on your definition of done. You'll probably start to see an obvious need for things as you start working through organizational or business concerns beyond just development concerns. In my current ...


7

You'll get a lot a conflicting opinions on this one. I typically like to specify happy-path behaviour and error behaviour in a single story unless that suddenly makes the story too large to work on. If error behaviour is complex then it should be its own story. My favourite way of clearly specifying what is expected in a story (just happy-path, or error-...


7

Problems like these are what your retrospectives are for, because there is no "one true agile way" that will work best for everyone in the world, or even every team in a company. Brainstorm some solutions, agree to try one for an iteration or two, then evaluate how it's going at the next retrospective and make adjustments. Were I sitting in on your ...


7

You say "I didn't do any work for those features to work properly" but that's not strictly true. While you didn't write any code, you did spend some time testing, and testing is valid work just as much as writing code is.


7

I would try to avoid such comments. Although I think there is a place for them where you have a particularly annoying requirement. Which without, anyone might want to refactor the code. eg. //must log to the database instead of standard logging, //stupid requirement from those crazy DBAs!! see TKCT-1234 or similarly you might put in a link //work around ...


7

"Non-functional requirements" is a bit vague and open to interpretation. Going on your specific example, I would say that those requirements should be used as acceptance criteria for other stories. If you are concerned about repeating the same non-functional requirements story after story after story, another solution would be to bundle all of these ...


6

If you're talking about a single product/project and a single pool of developers, I would strongly recommend having just one product backlog with all the items you mentioned included in it. Having two backlogs will be an admin nightmare, and I'd imagine that you and the product owner will be fighting for resources to work on your respective backlogs. If ...


5

It sounds like you've changed the definition, value, sensitivity of a story point (time, complexity, etc), so you're really doing a conversion and not a re-estimation. Unless there is more to it, it's no different then changing from entering in days and then changing to hours. Just do the math but it's really worth the same based on today's definition.


5

Your problem: Developer A branches from Master, developer B branches from Master, both work on closely related features, and the inevitable fact that the merges into the Master branch are difficult because of inevitable conflicts is what holds everyone back. If this is foreseeable, then A and B could first create a common branch, then each branch for their ...


5

The basic information needed in any error report: What exactly did you do? What exactly did you expect to happen? What exactly happened instead? There's a bunch of other information that can be crucial, but depends on the specifics of the system and your environment - things like what user account was used, what domain objects were being worked on, what ...


5

We use FogBugz, but I'm sure the same (or similar) applies here: We just use "Resolved (Fixed)" and comment in the resolution edit something like "Fixed by case 12345". FogBugz matches "case \d+" and links the two together under Related Cases, but if Jira doesn't do that, it should be simple to just add a link. This is IMO better than a "Too Localized" ...


5

In my opition global requirements belong to the definition-of-done because you do not want to update every matching userstory when a global requirement changes


5

For Code Comments, there is very little usefulness. For version control comments, they are very useful for reasons outlined below. Code comments really should be used to help understand the intent of complicated things. Bad types of code comments: Updated EHS 10/24/2015 -- if I wanted to know that, I would use version control to find who wrote which ...


4

I would say that what you are referring to here could better be called 'complexity'. Of course, the more complex a change is the higher the 'risk' is that some new bug may be introduced by an inexperienced programmer. It is not a bad idea to introduce such a field if it is a real issue. However, judging from what you wrote you seem to have two issues: You ...


4

Should I create user stories as super tasks and then create subtasks with the actual tasks/requirements? Yes, same reason as @superM gave. Our team actually puts all the acceptance criteria and requirements in the user story (super task) and then create subtasks to outline what exactly the developers need to do to accomplish that story (eg, create table, ...


4

We use Jira with an overly complex/customized work-flow thats supposed to be good for a small one man iOS game through to the next space shuttle deployment. Even as a team leader I cannot do things without getting an administrator involved. I cannot for instance, roll a defect marked as "fixed" back one step to "in action", so if I (or a team member) "fixes" ...


4

Its probably a change to an existing user story. ie. as a user given I have some memberships when click on the resign button the status should read 'cancelled' and an email should be sent blah.. User stories can be very small. Don't skimp on tracking stuff or it will just be raised as a bug in QA "i tested the page and it says cancelled instead of ...


4

Updating the due date to reflect a time estimate frankly makes no sense. The issue is already due before work started on it, whether that's tomorrow or in six months. Due dates are parameters to the development team, not feedback from it. The estimate field is what should be used to provide the estimate, either in story points, hours, etc. The product ...


4

Now, since I didn't do any work for those features to work properly, in order to reflect correctly what was done for those tasks should I close them unassigned in the backlog directly or put them in the sprint, assign them to me and close them? IMO you did some work: you tested it. Therefore, I would include in the sprint, assign it to me and close it. ...


4

You have the name your branch something. Some benefits of adding the Jira number: If someone is sick (or hit by a bus) other developers can find the open branch easily, on the ticket number If you have a lot of uncleaned branches someone can check if the story is finished in Jira before removing the branch You can integrate git (Bitbucket) and Jira to show ...


3

The handling of errors should be spelled out in the acceptance criteria, not in the story. The user story is all about functionality delivered to the end user, and presumably you aren't delivering errors to the end user. I can see a case for making error handling part of the story for a product that is targeted toward other developers, where error codes and ...


3

I think how you manage your Jira is really up to you and your team. We use a different issue tracking system to Jira that has the ability to create "virtual accounts". Our last lead developer used to like all issues assigned to him which he would then dish out. When I took over temporarily I created a virtual account called "Up For Grabs" and moved all un-...


3

A different team leader began assigning my name to the unassigned issues and changed the setting to the default assignee is myself rather than "unassigned". Does this sound logical? What happens when the task is not in the project backlog - are you removing your name? It isn't the end of the world to put your name there as a default if you remove it when ...


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