Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have bought Jira, Greenhopper and Confluence and I have been using their products, but I have not been very good at writing tasks properly.
Let say you have a task in your project that you know consist of several minor tasks, then you would make subtasks to the overall task. What happens when you have completed all the subtasks? Do you drag the overall task over as well (I mean the parent task)?
How do you write your tasks? Do you write them just like: "Create Customer table in database"? And if this task consist of making indexes, constraints etc do you write subtasks to it? Or do you write tasks in another way?
As all things management there is no common practice in this, but here are some guidelines I personally use and we integrate in our company.
The summary should be descriptive of the issue. It should not contain a word describing an issue type: bug, feature, task etc. That's what the "issue type" attribute is for. For example: "Re-check the site for any problems, resolve permissions issue" or "Text corrections".
It is good to have the Priority, Due Date, Environment, Component/s, Affects Vers, Fix Vers and Labels attributes - for those that you're using but keep in mind that the more attributes defined the more information an issue holds, the more descriptive it is and the more manageable.
The description field should hold all available information described in a formal manner.
Sub-tasking:
This solely depends on your organization, but there was a bug in Greenhopper that I personally reported and is now resolved:
"Sub-tasks' estimate does not show in Master Task in RapidBoard's Plan Perspective"
"We are experiencing a problem with rapid board sprints.
Our Master issue * does not have an estimation of its own, but does have an estimation when you include the subtasks.
As you can see from the attached screenshots, when we include this master issue in the next sprint, we do not see the estimation sum for all of its child issues.
They are not shown at all."
So for subtasking we now use this new (fixed) feature - the master tasks's estimate is the sum of all estimates for an issue. I personally subtask only when the master is something very complex, but with my job that's every day's work.
Hope this helps but again this is my personal opinion.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Our Supervisor mentality is that if a bug is found in the future he wants to do this:
Find the PBI that describes the functionality that is not working correctly.
Update that PBI to current Sprint.
Create a Bug and put it under that PBI.
Create a task and put it under that Bug.
The rationale behind this is that he considers that PBI to not have correctly finished, so it has to be re-opened, and he wants the Bug to be under that PBI so that he knows what functionality was not working correctly.
I'm under the impression that the correct way really only has 2 options:
Treat Bugs at the same level as PBIs when you find them in a future iteration - create the Bug but just be as descriptive as possible so you know what functionality was the problem.
Treat the Bugs as a Task, so either create a new PBI, or copy\move the previous PBI to the current sprint, and put the Bug under that PBI, but DON'T create a task under the Bug, the Bug essentially is a task.
What would be a solution for our shop?
Actually you just need to associate the work items (PBI > Bug > Task). Once the association is created, then you can find the linked work items under Related Work.
In my opinion, both options are OK. The two options you mentioned only reflect how the work items shown on backlogs and boards. But if you already linked the related PBIs, Bugs, Tasks, then open any of the work items you can find the relationship between them (Parent/Child ~ where the bug came from).
For example:
Treat Bugs at the same level as PBIs (Bugs are managed with requirements)
Treat the Bugs as a Task (Bugs are managed with tasks)
UPDATE:
Both of them can not completely achieve your requirements (No better ways to achieve that based on the current features ).
However if you are more concerned about where the bugs come from, then option 2 ( Treat the Bugs as a Task) is better, as it can show dependencies/relationship intuitively in backlogs (Bug is under specific PBI).
If you are more concerned about the hierarchical structure of the work items, then option1 (Treat Bugs at the same level as PBIs) is better (PBI > Bug > Task).
Whatever you can find where the bug comes from via the related link.
A lot of teams I work with categorize bugs in one of two ways:
Bugs found in a sprint on items worked on in that sprint
All other bugs
For bugs found in a sprint they associate them with work item. All other bugs are treated as stand alone backlog items.
There are several reasons for this, including:
When a bug is discovered some time after the work is done it may be difficult to work out which work item it is associated with
Not all bugs neatly associate with a single work item, particularly ones not found in-sprint
Bugs found in-sprint should be immediately addressed or the work items will typically not meet the definition of done
Bugs found out of sprint need to be prioritised alongside other work items
Unless you have a specific need to associate bugs with work items (for example it is part of a billing mechanism) then any effort you put in to this could be considered to be waste. Associating bugs in-sprint with work items does not require much effort and so does not generate much waste. Doing it with out of sprint items is often quite costly in time and may be difficult to justify.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am some way through a project, on the 3rd sprint, which is about back-end processing. Let;s say the sprint name is "3. Data merging and form generation". I have 4 or 5 features in that sprint relate directly to that task, and I'm halfway though- some completed, some not, one in progress.
While in this sprint, I demonstrated some of what was happening to the client, who promptly (kind of unexpectedly) gave me a few pages of feedback purely to do with the UI. Very front-endy stuff, nothing to do with my current sprint, but still relevant and good stuff.
It seemed that at that time, it would be appropriate to drop my current back-end work and address the feedback. The reason being by addressing the UI issues, it would stop propagation of 'wrongness' to the rest of the application (Lotus Domino: That's how it works).
JIRA doens't have a facility for putting Sprints on hold, and starting a new one. You have to close a sprint.
Adding a feature to my current sprint would be fine, but would include a load of UI issues in a sprint names explicitly to do with the back-end processing.
It felt like square-peg-round-hole, and I'm not sure how this is 'supposed to' go with Agile, or JIRA.
So my question is: Is the problem that ..
Naming of Sprints shouldn't include too much commitment to their nature, so including a UI task with a sprint intended for the back-end processing woudn't be upsetting things.
If a sprint is "interrupted" like this, my notion of putting it on hold and sidetracking to another sprint isn't how Agile works (hence JIRA won't let you). Something else should happen (if so, what?)
JIRA is less flexible than Agile demands (seems very unlikely!)
Some other thing I haven't thought of.
The typical approach to scope changes mid-sprint is as follows:
If a change is relatively minor and both the team and the Product Owner agree then you go ahead make it. Typically a team will compensate for any changes, for example when they bring in a new story they would also take out a similarly sized story so that the net effect on the sprint is close to zero.
If the changes are significant the Product Owner may terminate the sprint. The team immediately starts planning for a new sprint in the same manner as usual.
It isn't all that common to name sprints with details of what the sprint contains. Just using a simple numerical sprint name (e.g. sprint 1, sprint 2) can help to make it clear the Scrum team is open to change.
In JIRA, if a sprint was terminated early I would mark it as complete and then create a new sprint. This may mess with your velocity calculation a little, but should be easy enough to compensate for.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Improve this question
Foreword: One could argue this question would be more at home on Law SE, but considering most lawyers aren't even aware of what a hackathon is, this question has a far greater chance of being properly answered here. If you disagree with that judgement, definitely let me know.
Now onto the good stuff
I personally love hackathons. They're a chance to develop some of the most useful skills in programming, like teamwork, rapid debugging, problem simplification, sleep deprivation tolerance, and that ability to turn an idea into a usable product as quickly and efficiently as possible. And yet there's something nagging at me: at some of the bigger hackathons, genuinely great ideas come about, ideas that could seriously be worth something. For example, Techcrunch Disrupt SF produced BlazingDB, a means of running very expensive database queries through GPUs, which is fairly genius considering any query on a distributed database is basically already a map-reduce operation, and that's just one name from the first hackathon I thought to google.
So who owns the products produced at a hackathon? The host? The creators? The sponsors?
This will be subject to the terms of conditions that you agree on when you join a hackathon. I for example will join a 2 day innovation hackathon next week and had to obey to the rules stated in the confirmation of participation policy.
It should usually look like this:
Confirmation of participation
I confirm my participation in the 'NAME OF HACKATHON' event on 'DATE and VENUE'. I understand that all outputs created at the above hackathon event will be on the basis of the 'NAME of LICENCE' as detailed at 'WEBSITE WHERE TO FIND'. By participating in this hackathon event, I hereby give permission to 'HOST NAME' to use any pictures and videos taken during the event that include myself for the purposes of organization promotional material and publications.
Mine used the following license: https://creativecommons.org/licenses/by/4.0/legalcode
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have the following question.
Often in our project issues stay in progress forever.
To resolve this we would like to introduce a new workflow where if a JIRA issue has been idle for 2 weeks it will automatically have its status set to Postponed.
How can this be implemented in JIRA? I checked the column constraints on the board, but there is no constraint related to time.
I think you don't have to build a workflow to mask your problem with regards to the "Issues which stay in progress forever", but you need to fix it.
Fixing it means you need to coach the team and support them with various technics to avoid "never ending stories". I would suggest to:
Implement DOR (Definition of Ready) - avoid picking up issues which are not yet investigated, groomed and not enough clear to pick up. In our case the story could be added into the sprint just after all external dependencies are sorted out. Use the INVEST model which says INDEPENDENT How can you commit to deliver issues where you depend on any external team?
Slice big stories - There are plenty of technics how to split large user stories. In general its a bad practice to add a story into the sprint if the estimate shows that it can't be completed. Ideally the right size of the story is "that you have 2,5 story to each dev in single sprint". This doesn't mean that every dev should work on his own story and they can't collaborate, but it means that for e.g. 4 devs for a single sprint 8-10 stories are ideal. (Easier testing, collaboration, better planning, more stable velocity, etc etc..)
WIP (Kanban limit work in progress) - Putting the 'flow' back in workflow with WIP limits - Atlassian This is something which is easily configurable in Jira.
Show the 'DAYS IN COLUMN' indicator on cards - This shows a series of dots on each card (up to the width of the card or a maximum of 32), representing the number of days that the issue has been in the column. This could be a useful info for the scrum master to see whether there is any impediment which should be sorted out
Don't use blocked or postponed status. This is just my personal advice. Statuses like blocked/postponed could generate a habit that the issues will be really just postponed instead of removing the impediment and blocker. It is always easier to flag something as blocked as removing the impediment. Its your scrum masters responsibility to remove the obstacles and eliminate the waste.
Backlog grooming - Groom the backlog periodically and if you have problems with the external dependencies flag them in advance. Seek for external dependencies by purpose and identify them as soon as possible. This will give the SM/PO hopefully enough time to deal with them before the issue will be added into the sprint and picked up by the dev team.
Why an issue is sitting idle for two weeks? Is it because of external dependencies or issue is too big to complete in two weeks?
I am not sure about the Jira work flow and if Jira can move it to postponed state. But you can move it back to backlog at the end of the sprint.
But if it happens because the issue is too large to fit in two weeks, then I would recommend to slice it into smaller tasks to fit in sprint.
I hope it helps.
If we ignore the arguments how good a workflow and its management is raised by #shippi the solution to this question is explained here.
https://community.atlassian.com/t5/Marketplace-Apps-questions/ScriptRunner-how-to-change-status-of-an-Issue/qaq-p/628842
Shortly said Jira has ability to execute scripts , they can also be scheduled and executed on regular basis. What needs to be done is a script to be written and scheduled that every day checks how long an issue has been idle and set the appropriate status.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
We use Jira ( plain jira, no greenhopper ) for project/task management and a separate system for time tracking.
How can I run a report to extract all the hours I have worked in the last week?
You can create a custom filter with a custom search query:
project = "My project" and timeSpent is not null and updated > startOfWeek("-1") and assignee was CurrentUser()
More information on JQL is here - https://confluence.atlassian.com/display/JIRA/Advanced+Searching#AdvancedSearching-Updated
Work already completed
One way would be to install the timesheet plugin which generates a tablular breakdown of time logged against projects, tasks and lets you export the information in Excel.
I've install the plugin quickly to get an idea of how well it works;
I think this is what you're looking for when producing retrospective time data.
Remaining Work
You can make use of the User Workload report which..
displays useful time tracking information on issues assigned to a
particular user. It shows the number of unresolved issues assigned to
the specified user, and the workload remaining, on a per-project
basis.
To create a report, you need to view (any) Project page, then select "User Workload Report" from the "Reports" link on the top right of the Summary screen. The JIRA Documentation has more instructions.
As an example, the report generated for myself is as follows;
You can also try our plugin Intelligent Reports. It lets you design the output format you want in Microsoft Word, and fill in the data using simple point and click rules, which allow you to filter, sort, etc. on all attributes of logged time.
It even comes with two timesheet example reports, a project timesheet and a cross-project timesheet. These should be easily adaptable to what you need.
As a quick note, JQL alone cannot filter logged time data completely, as it only returns issues. For instance, in the query given in the other answer, it will miss any work you may have logged against an issue that is assigned to someone else. Intelligent Reports lets you start with a JQL query, but further refine it using the attributes of the logged time directly.
You can use "JIRA Timesheet Reports and Gadget" for that, it generates beautifully structured report with wide range of configuration options.
It costs money, BUT it's only for extra functionality like "Working Days" or "Subscriptions". Main timesheet report functionality is free.
It's preinstalled for OnDemand or you can install it for your hosted instance. You can use it without a licence as I described.