Feel free to download this JIRA Cheat sheet with the list of shortcuts as well as many available operators of JIRA Query Language (JQL) for advanced searches.
JIRA is definitely a flexible bug tracking tool and one of the most powerful features is workflow customization. This post describes how to add a label automatically when an issue is created. This can be useful when you want to flag an issue and later capture that in a filter or board. A practical example is to flag Bugs that are created so that they can be reviewed during Bug Scrub meetings. In order to add a label we need to add a custom script in a post-function.
- As admin, go to Administration >> Issues >> Workflows >> Click on Edit in the workflow you want to change
- Click on the ‘To Do’ step (assuming your workflow is the default one)
- Click on the ‘Create’ action >> Post Functions tab >> Add post function
- Select Script Post-Function >> Custom script post-function
- Paste the following code snippet replacing ‘BugScrub’ by the tag you want
- Publish the workflow => Important: If you don’t publish the draft workflow, no changes will be reflected.
import com.atlassian.jira.ComponentManager import com.atlassian.jira.issue.label.LabelManager import com.atlassian.jira.component.ComponentAccessor def user = ComponentAccessor.jiraAuthenticationContext.getLoggedInUser() LabelManager mgr = ComponentAccessor.getComponent(LabelManager.class) mgr.addLabel(user, issue.id, 'BugScrub', false)
For additional information about the addLabel method, please refer to the official documentation.
JIRA is one of the most used bug tracking system and one of its main features is the search mechanism. There are two modes when searching for issues on JIRA: Basic and Advanced. The basic one is composed of a set of filters you can select and define values. Even though the basic mode is enough for most cases, it does not allow you to run some more complex queries.
Today I’ll present the WAS operator that can be used by writing JQL queries in Advanced mode and that allows you to search for issues based on the property values in the past. This can be extremely useful if you want, for instance, to collect history data or to evaluate changes against to such a property.
This operator can only be used with the following properties: Assignee, Fix Version, Priority, Reporter, Resolution and Status fields only.
Find all bugs that were open last week
issuetype in (Bug, Defect) AND resolution WAS IN (Unresolved, EMPTY) before endOfWeek(-7d)
Find all stories that were resolved last week and that are now closed
issuetype = Story AND status WAS Resolved DURING (startOfWeek(-7d), endOfWeek(-7d)) AND status = Closed
Find all stories that were unassigned in the last two days
issuetype = Story AND assignee WAS EMPTY DURING (endOfDay(-2d), now()) AND assignee IS NOT EMPTY
I’d like to cover one topic that may be a little controversial among managers or agile practitioners: whether planning sprints in advance is acceptable or not in a Scrum project. Should I plan only the Sprint my team will start or should I plan future Sprints?
Being agile is about identifying and reacting to problems as soon as possible. The three pillars of a Scrum project emphasize how to do that by inspecting, adapting and being transparent during the Scrum events. However, there is no Scrum event to go beyond the planning of the current Sprint. This is why the most purist people don’t plan future Sprints.
Even though Scrum guide does not mention this, positive results may be realized when planning more Sprints in advance. These are some benefits of doing that:
- Anticipate problems that require immediate actions
- Increase likelihood of meeting external milestones (i.e. those that do not depend on or cannot be controlled by Scrum team)
- Identify need of hiring new people for the team
However, how can this be done without impacts (or with minimum impacts) in the current sprint, since team members should be focused on developing the scope of the Sprint?
Slightly change Backlog grooming sessions can be a good alternative. During grooming sessions the Scrum team and the Product Owner discuss about the Product Backlog with a clear goal: finish the meeting with an improved Backlog. The definition of “improved backlog” can vary from team to team, but usually attendees focus on detailing more the user stories and their acceptance criteria. However, these sessions can also be used to create sub-tasks, to estimate and to assign them.
With a Backlog with sub-tasks and their estimates, the Scrum Master can distribute Product Backlog items in the future sprints, based on the Product Owner prioritization. Having done that, it is possible to check if some milestones look feasible, if people are over-allocated, which may require hiring new people to meet some dates and features, and so on. In addition to this, having 1:1 meetings between the Scrum Master and each team member, once a Sprint for 30-60 minutes, to review estimations and assignments improve the accuracy of the Backlog. This would require an additional effort for the Scrum Master of about 8 hours / sprint, considering a 8-member team, as well as a total of 8 hours when summing up 1 hour of each member. This can be an important practice to mitigate risks.
Important: What is planned for future sprints is not a commitment. A Scrum team can only commit to a Sprint goal after the Sprint Planning.
‘Being creative’ is a skill that many companies require employees to be, but sometimes neither the company nor the employee have a basic understanding on how to leverage a creative thinking. For the last few weeks I’ve been taking a Coursera course (On Strategy : What Managers Can Learn from Philosophy – PART 1) and Luc de Brabandere shows a simple but effective way of differentiating when you are thinking about something new or when you are just applying logic or past experiences.
Human beings apply models to solve a problem, i.e. they make a simplification of the problem and try to fit it in a pre-existing box that may have address a similar issue in the past. Basically, when we see a problem in the world, we pick one of the models in our mind and then we come up with a proposal of solution. This is called deduction and is the most common and faster way of thinking, since our brain is ‘lazy’ and tries to follow the shortest path to answer such a question.
However, creating something new goes a way beyond of only applying pre-conceived models. Inventing something is more related to analyze a real-world issue and then come up with a new model for handling that. This is called induction.
To exemplify, think on how to categorize the following words:
- Rio de Janeiro
- San Clemente
- Washington DC
- Jeffreys Bay
- Buenos Aires
You may think about separate these cities in two groups: capital or non-capital. Or maybe in US cities and non-US cities. Thinking in this way, you are applying models you have on your mind to solve the problem of categorization and that are widely adopted, what makes your brain bringing them firstly. This exemplifies deduction. However, if you try to think out-of-the-box, you can come up with a new model (at least for you) to separate cities that 1) are in the coast and which name is composed by more than one word and 2) cities that does not satisfy the aforementioned condition. This is an example of induction.
The very first step for creatively thinking may be to understand when you are deducting and when you are inducting, so that you can switch them when necessary. Both deduction and induction are important and compliment each other. Although induction is not the approach adopted by us in most cases, training our mind may help us to be more creative.
If you get interested about this topic, I’d suggest you to take the Coursera course to go deeper. Thank you.