WAS operator in JIRA

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

Should I plan future Sprints?

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:

  1. Anticipate problems that require immediate actions
  2. Increase likelihood of meeting external milestones (i.e. those that do not depend on or cannot be controlled by Scrum team)
  3. 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.


Release Planning in Scrum projects

Even thought the Scrum guide does not mention a Release Planning ceremony, usually, after having a prioritized backlog, the team performs a Release Planning to lay out what could be released in each iteration based on the team velocity.

The result of a Release Planning can cause some misunderstanding if its definition is not clearly shared among all stakeholders. When distributing the Backlog in Sprints, people may see that as a commitment of the team to release those features at that time. If the team does not release what expected, then they are “failing”. It’s worth emphasizing few topics at this point:

  1. I’ve never seen an accurate estimation of team velocity in the early beginning of a project and I triple-dog dare any of you to present a method to accurately do that. In the beginning of a project the scope is barely understood, there are new people in the team, the environment and time are different of any previous projects, team members live different moments on their personal and professional lives and so on. There are more variables than equations to solve this problem. So, accept and share that the estimated velocity is unlikely to be accurate.
  2. Scope is dynamic in 100% of the projects. The scope considered in the beginning of the project is certain to change. New features may be added while some may be dropped.
  3. If the scope is dynamic, the plan is consequently dynamic too. Regardless on how your team defines a plan, there is only one certainty about it: it’s going to change throughout the project.

People need to understand the plan of features for a Sprint is a draft until the Sprint Planning for that Sprint happens. Before that, there is no commitment of features for that Sprint.

But wait! What is the purpose of planning features for future Sprints if there is no commitment and if they are likely to change? The answer is simple: to be agile. Being agile is also about identifying and reacting to problems as soon as possible, by inspecting, adapting and being transparent. If you plan few Sprints in advance, you may anticipate some problems that demand immediate actions.

Understanding a way to creatively think

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

Deduction vs. Induction


To exemplify, think on how to categorize the following words:

  • Rio de Janeiro
  • San Clemente
  • Dallas
  • Rome
  • Washington DC
  • Jeffreys Bay
  • Buenos Aires
  • Miami

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.