Hot answers tagged

48

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 ...


19

In my experiences, stories are either done or not done. There is no concept of an unfinished story. At the end of a sprint, you either completed the design, implementation, testing, integration, and system testing for a story and presented it to the customer for sign-off, at which point it was moved out of the backlog or it remained in the backlog for the ...


11

You should fix a bug only if the application is more valuable without the bug. If a text field is misaligned and it takes three days to fix it, then the cost is probably too high and you should leave it. On the contrary, if the users cannot write at all into the text field then you should fix it, and quickly. In general it is easier to fix an issue ...


11

These are good first contact bugs to fix for new developers that have just joined your company. Or for junior developers to expends their knowledge of the system. If not, you can mark them "wont fix" if they are not serious enough to justify the time it would take to fix.


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 ...


11

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 ...


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 ...


9

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 ...


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

The iteration size is supposedly fixed. The best approach (according to me :) ) is to split. Typically when tasks are not completed within the iteration they are assigned to, I suggest splitting the user stories and move the incomplete tasks to the next iteration. The estimate of the new user story is calculated from the remaining units necessary to ...


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

In our issue-tracking, there is a status "time-barred". If an issue is several months or even years old, and no client urges or refiles the issue, then this status is used as the final status. This is not done automatically, but manually, whenever the managers ask us to clean up the open issues. During this process, it's also likely that some of the issues ...


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

I've found that if you can provide valid numbers, managers are more likely to act. (If they can understand the logic and the cost/benefit.) IMHO, to make a convincing case, you would need the following to show how bad it is: number of support incidents logged for the issues time spent in hours maintaining/band-aiding bad code/doing support fixes time cost ...


5

A. Put the story into the project backlog. If it's still the most important thing, it will be scheduled for the next sprint. If not, the product owner will schedule something more valuable. B. You get no points for that story for this sprint. When you schedule the next sprint, Only count points for stories completed this sprint. (Yeah, you'll pull in a ...


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

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

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

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 ...


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

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 ...


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