Your agile dashboard: Inform to win!

Hey agile ninjas! One of the questions I get from time to time is how to configure JIRA’s dashboards to show content that’s relevant for agile teams. About a year ago, Christina Bang published an excellent article about how to build a killer dashboard in JIRA. If you’ve not read her article, please start there first. We’ll build on a number of concepts in her article as we extend it for agile teams. We will focus on scrum, but many of these tips apply for kanban teams as well. Also, we recently launched our new Do Agile Right microsite, so if you are looking for some agile tips, check it out!

JIRA is very flexible and can satisfy just about any workflow or process. To meet the needs of a team using agile project management, we first want to configure the JIRA dashboard to reflect an agile process.

Step 1: The sprint health gadget

New in JIRA Agile 6.3, the sprint health gadget easily summarizes all of the key metrics in a sprint. I like to have this one in the upper left so that everyone can see who’s working on the sprint and get a quick sense for any trouble in the air.

Step 2: The burndown chart

The agile sprint burndown gadget shows the track record of the team throughout the current sprint. The beginning of the sprint is on the left and the end of the sprint is on the right. In general, we want to see the remaining values stay under the guideline. For this chart to be accurate, estimation in the beginning of the sprint is critical. The chart uses the estimates to draw the guideline. What are the flat spots in the guideline? JIRA Agile has the ability to configure nonworking days. This team is trending to not meet its sprint commitment. Isn’t it better to know that early?

Step 3: High priority issues

I like to have a list of high-priority issues for my team in the upper right-hand corner. I can use a JQL statement to find any issue that is flagged, as well as any issue that is considered a blocker. Why flagging? Flagging issue means that there’s an impediment for a team member to move forward. If an issue is marked priority = blocker, then that issue is globally important to the health of the project. Both are of concern to the team to resolve, but for different reasons. The statement JQL statement is:

We can then create two instances of this gadget showing assignee by state as well as assignee by priority.

Step 4: The two-dimensional filter statistics gadget

While a mouthful, the two-dimensional filter statistics gadget packs a real punch! You can configure it to show a set of data densely so that it’s easy to find key areas of concern. Using this gadget, I want to know two things: How much does each team member out on their plate, and what are the relative priorities of work distributed throughout the team. Let’s consider all of the open work in setting up our base filter. We can use the following JQL statement to show the work in the current sprint as well as future scheduled work:

Step 5: Continuous integration!

The most successful agile teams live and die by their continuous integration. Consistent, effective investment in automated testing strategies by the entire team enable agility like no other effort. Using Atlassian Bamboo, teams can stay on top of build breakages, and ensure that automated tests are running in top condition. When the build breaks, everyone suffers.

Step 6: See the incoming funnel

It’s important to see what work is not yet done. Some teams like to assign out work at the sprint planning meeting. For this case, you can use the assigned to me gadget so that each team member gets a gadget listing their work. For teams that assign work as it moves into the in progress state, you can use the filter results with this JQL query:

Step 7: What’s next?

Teams don’t live alone. You can extend your dashboard to include data from multiple teams. Need to track multiple scrum teams together? Use several instances of the sprint health gadget alongside the burndown chart to get a quick overview of how all teams are progressing towards a common goal.

Ready to take project tracking to the next level? Engage in a 30 day trial of JIRA and JIRA Agile today!

Try JIRA Agile today

Before I started working in video streaming, I had never heard of the term “10-foot UI.” For those who haven’t heard this one yet, a 10-foot UI is the user interface specifically designed for use on televisions and large screens. Why is this interesting for us? Because JIRA can be used on a television screen, and it’s actually really useful.

Every moment of every workday, we’re processing information; from people talking to us, our computers, or just walking around the office and taking everything in. How do you parse it into usable data? Enter JIRA’s wallboard view, which is a 10-foot UI experience for JIRA. Wallboards give you a central, consistent way to display key project indicators, so no matter what’s going on around you, you always have instant access to crucial data. As a bonus, everyone who walks by can get easily see how the team is doing.

You can do some pretty cool things with wallboards, which have their beginnings in JIRA dashboards. Whether you’re an agile team or a traditional software development team, wallboards can build off your existing dashboard (agile pr traditional) to show off your team’s progress. We will focus on agile teams, but the same concepts apply for traditional teams.

Step 1: Create your dashboard

Dashboards used as wallboards are focused on the 10-foot UI experience. Not all gadgets are wallboard compatible, but the ones in this article are. I’d use the following gadgets:

• Agile sprint health  – A great view of all the key metrics in the current sprint
• Agile days remaining  – Clearly shows how many days are remaining in the current sprint. Not everyone viewing the wallboard will have the team context.
• Agile wallboard – A beautiful way to highlight the flow of work for the team in a 10-foot UI experience.
• Bamboo builds – Showing everyone the status and health of the build gives visibility to the most important metric your team maintains.

For configuration tips, please see: 7 steps to a beautiful and useful agile dashboard.

For those of you that read my prior blog, I don’t use the agile wallboard gadget on a traditional dashboard. Traditional dashboards are used within the context of JIRA. Thus, it’s easy to jump over to the actual agile board to see that view. With wallboards, the viewer is not inside of JIRA, so it’s a great way to visually show the flow of work for team in that moment in time.

Step 2:  Customize its look

Large monitors usually have a much wider width then height. For this reason, I like to use the two-column view where both columns have the same width.

I’ve minimized each gadget to just show the headers to make seeing the header colors easier. I felt like both the agile sprint health gadget and the agile sprint burndown gadget showed similar information, so I made them the same color and put them in the same column. When viewed in wallboard mode, these gadgets will rotate. Since all of the other gadgets have different colors in their respective columns, they will always show. Let’s take a look at the two rendered views:

Pretty cool, right?

I would think carefully about which gadgets to keep static, and which gadgets to rotate through in your wallboard. I find that the days remaining gadget can keep everybody focused as to where they are in the sprint. Take a look at how I configured this example dashboard to become a wallboard. Note the header colors of each of the gadgets and how they rotate through in the wallboard version. You can click on each of the images to see a high-resolution version.

Step 3:  Extend your wallboard to support multiple teams

Do you have multiple teams sitting in a combined area? With JIRA, wallboards can be strung together to run in a carousel. You can set up a wallboard slideshow to have multiple teams display on one monitor.

Most of all, have fun with it! Wallboards can be an expressive way to share the team’s progress and success with a wider audience. Wallboards are extensible by adding new gadgets and with custom styling.

Ready to supercharge your team with JIRA?  Start with a 30 day OnDemand trial of JIRA today!

This post is the second in a Do Agile Right mini-series about about agile maturity. Matt Schenck is a Product Advocate with Atlassian. His experience implementing agile tools at companies of all sizes gives him a unique perspective on how tools and methodology coexist without disobeying the Agile Manifesto.

We closed out an excellent 2013 Atlassian Summit with a plethora of great talks, many of which got me thinking – but none more so than that of Damon Poole, Chief Agilist at the Eliassen Group and his talk on the Enterprise Agility Model. One of the topics that he discussed was the “path to agility.” So often I talk to customers who are focused on achieving agile governance, often time skipping over the fact that they are struggling to run good sprints, or a good release, or even a great program. Most companies realize that going agile is a process, and that it takes education, coaching, and a relatively strict adherence to agile methodologies. A surprising amount of people tend to overlook the idea that it takes work to transition from beginner agile to advanced agile.

Tracking agile maturity in JIRA Agile

That’s why we have taken the Agile Maturity Matrix from Eliassen’s Agile Thought Leadership team, and converted it into, well, a JIRA Agile project. Understand that the Agile Maturity Matrix is not a quiz to make you feel x% agile, but rather a tool to give you a real sense of where you are at today, and to make incremental commitments to becoming a more sophisticated agile enterprise. In other words, there’s no need to cheat!

With that, I have outlined how to import this project into JIRA and assess your agile maturity with “Sprint Zero.” From there, you’ll have the foundation to start making commitments to where your organization is going on the path to agility.

How to upload the Agile Maturity Matrix into JIRA

1. Log in to JIRA as a user with the JIRA Administrators global permission.
2. Select Administration > System > Import & Export > External System Import > Import button associated with the Comma-separated values (CSV) option to open the CSV File import page.
   Keyboard shortcut: g + g + start typing external system import
3. On the CSV File import page, select the JIRA Agile Maturity Matrix.csv. 
4. Leave the Use an existing configuration file check box cleared if you do not have a configuration file or if you want to create a new configuration file. Configuration files specify a mapping between column names in your CSV file’s header row and fields in your JIRA installation.
   Note:
   • If you select this option, you will be asked to specify an Existing Configuration File.
   • If you do not select this option, then at the end of the CSV file import wizard, JIRA will create a configuration file which you can use for subsequent CSV imports (at this step of the CSV file import wizard).
5. Click the Next button to proceed to the Setup step of the CSV file import wizard. Select the option for “Defined in CSV.”
6. Click the Next button to proceed to the Fields step of the CSV file import wizard. For each CSV field that is presented, you will need to select the exact same JIRA Field from the Picker.
7. Click the Next button to proceed to the Values step of the CSV file import wizard. Click Begin Import.

8. This should upload 300 issues successfully. 

9. In the JIRA Toolbar, hover your mouse over the Agile drop down, and select Getting Started.
10. Select the Scrum section and click Create a new board.
11. Select the Board from an existing Saved Filter option.
12. In the Board Name section, enter Agile Maturity Matrix. In the “Saved Filter” section, enter Agile Maturity Matrix.
13. Configure the Board as follows:

• Select the Swimlanes tab. In the drop down menu, select Base Swimlanes on Stories.
• Select the Estimation tab. In the drop down menu, select Estimation Statistic: Issue Count.

View your agile maturity using the backlog

Once you upload the data set and create the scrum board, you’ll see the following backlog with the 50 elements of the Agile Maturity Matrix, all in the form of JIRA Stories. Additionally, these stories are grouped into Versions, similar to the Agile Maturity Matrix itself. As you work towards becoming “Ideal” on a User Story, you will start seeing progress along the Version Bar.

Assess your agile maturity – aka Sprint Zero

In order to track your way to Ideal Agile, you need to know where your organization stands when it comes to agile. To do this, create a new sprint, and bring all 50 stories into this Sprint Zero.

Once you have started the sprint, go into your Work mode of your Agile Board. All of the steps towards Agile Maturity are actually logged as subtasks of each Story. As part of Sprint Zero, you need to indicate where you are at but moving all completed steps to the Done column:

In this example, when it comes to the Organizational Structure, the company’s organization is beyond function and project based, and there is an understanding that teams are structured around products and teams, however the organization is still working on consistently becoming a product, team and delivery based company.

Today we’re excited to present a new customer story with Starz Entertainment, the global media and entertainment powerhouse behind hit TV shows like Spartacus and Mad City. Headquartered in Denver, Colorado, Starz Entertainment has been evolving since 1991 to meet the demands of an “anytime, anywhere” audience.

To overcome this challenge, Starz has been moving towards a leaner, more agile software development process. Engineering and business teams at Starz use JIRA as the single source of truth for anything related to software development, from ingesting tapes to launching digital marketing campaigns.

To support the engineering teams, JIRA is further integrated with Bamboo, Confluence, FishEye, and Crucible. Starz also uses Zephyr, a plugin made by GetZephyr, for test case management, Gliffy for mockups, and Tempo for time tracking.

By managing its entire application lifecycle in one toolset, Starz’s engineering and business teams are constantly working together to meet release deadlines. How’s that for doing agile right?

Click the video below for a peek at the engineering teams behind the camera, the “magicians” (so to speak) responsible for bringing your favorite shows to you!

The post Doing agile right at Starz Entertainment appeared first on Atlassian Blogs.

Software development is intensely collaborative, requiring the effort of numerous people on many different teams. With so many stakeholders, it’s difficult to maintain speed, transparency, and quality when shipping code. Most development teams accept these things as facts of life when building software, but this doesn’t have to be the case any longer.

Building better software starts here

Today’s release of Confluence 5.4 brings JIRA into Confluence – and Confluence into JIRA – like never before, so your team can build better software, faster. When we say seamless integration, we mean it. We’ve made agile best practices the easiest practice, for your team and every team.

The flow of agile development

Before we dig into the details, let’s take a step back. We identified four key phases that agile teams flow through when building software, and we’ve focused on making the transition between each phase as seamless as possible.

1. Define – Standardize your product requirements in Confluence, and track and manage the changes as they evolve over time.
2. Plan – Turn requirements into JIRA stories and jumpstart development, while always maintaining traceability back to your requirements.
3. Report –  Communicate the progress and achievements of your development team to the rest of the business to keep everyone informed.
4. Improve – Reflect upon and improve your process by running retrospectives as you complete sprints.

Confluence and JIRA: Two products, one flow

Half the teams that use JIRA also use Confluence. Development teams live in JIRA where they track their work; The rest of the business lives in Confluence where everyone collaborates around requirements, documentation, marketing plans, sales reports, and anything else that supports taking a product from concept to launch.

New integration features break down the barriers that separate your development team from your product managers and the rest of the business, streamlining how you plan and track your releases. Now you can standardize your requirements, maintain traceability, and continuously improve with one seamless flow between Confluence and JIRA.

1. Jumpstart development with product requirements

Building great software requires even better planning, so we’ve made it easy to define your product requirements in Confluence where they’re standardized and customizable for your own processes. Using the Product Requirements Blueprint, anyone on your product team can contribute – your product managers, developers, and designers – and write the most informed requirements possible, helping the whole team plan to build quality software from the get-go.

Turn requirements into JIRA issues, seamlessly

Once you have a completed and agreed-upon set of user stories, the next step is to get them into your team’s backlog in JIRA. Now you can do just that without even leaving Confluence, no copying and pasting required. Just highlight a user story – or any text on a Confluence page – and click the Create JIRA issue button that appears.

The days of creating JIRA issue after JIRA issue are over

If you highlight text in a table, you’ll be given the option to create issues for every row of the table (or every user story in this case) so you can create all your issues in one fell swoop. How awesome is that?!

2. Maintain traceability with automatic linking

Confluence automatically embeds your newly created JIRA issues in your requirements document, so it’s easy for your product managers to keep up on the progress of the development team’s work being tracked in JIRA.

Confluence links everything together for you

Product managers can now get a single, dynamic view of all the sprints, epics, and issues related to your requirements at the top of the page. Just click through into JIRA for more information.

Access linked Confluence pages from JIRA Agile

In order to build what’s been specified, your developers need quick access to related documentation in Confluence. Your requirements – and any other Confluence page, such as technical specifications or design guidelines – are automatically linked to your epics and issues in JIRA Agile so your developers can get all the context they need without breaking their flow.

3. Communicate progress with JIRA Reports in Confluence

If you’re a product manager or development manager, how many times have you been asked about the current status of the release? Stakeholders rely on what your team is building, but they don’t have visibility into your team’s progress so they always have to ask.

Now you can give them the transparency they need before you even get the question. Using the new JIRA Report Blueprint, you can communicate the progress of your releases with quick-to-create ad-hoc status reports and change logs.

4. Reflect and improve with retrospectives

Agile development is easier said then done, so we’ve built an agile best practice right into Confluence. Once your sprint is finished, it’s important to reflect on your team processes so you can make the next sprint better. That starts with running a retrospective with the new Retrospective Blueprint in Confluence.

Kick off retrospectives in Confluence from JIRA Agile

When your scrum master has completed a sprint in JIRA Agile, they they can kick off a retrospective in Confluence with a single click.

Define what went well, what didn’t, and what could be improved for next time by assigning tasks.

Start building better software today

Free your development team from the everyday frictions that slow them down. Plan and track your next release the right way with new, seamless integration between Confluence and JIRA.

OnDemand customers

You’ve been auto-upgraded. Enjoy!

Download customers

• For the ability to create JIRA issues from text in a Confluence page you need to upgrade to Confluence 5.4 and have an application link toJIRA 6.1.3 or above.
• For the ability to view linked pages and start retrospectives from JIRA Agile you need to upgrade to Confluence 5.4 and have an application link to JIRA 6.1.3 or above with JIRA Agile 6.3.5 or above installed.

New to Confluence?

Get up and running in a matter of minutes with a free 30-day Confluence and JIRA OnDemand trial.

The post Confluence 5.4: Integrated with JIRA like never before appeared first on Atlassian Blogs.

Here at Atlassian we’ve been focusing a lot on user experience – a year ago, we introduced the Atlassian Design Guidelines (ADG), which serve to unify the customer experience across all of our products and add-ons with a  simple, and straightforward approach.

JIRA goes ADG

JIRA 6, released May 2013, is now ADG compliant with a more modern and beautiful experience. The header is now consistent with other products and easier to customize. Typography, spacing, and overall layout are uniform throughout JIRA as well as in other Atlassian applications. (To learn more about the design process in JIRA I’d encourage you to check out the interview with Ross Chaldecott, JIRA’s design lead: Part 1/Part 2.) Good design though is not a moment in time. It’s an iterative experience of listening to your customers, and using that feedback to make the product better. As we did this, it occurred to us that an issue’s status is a central part of the JIRA experience. In fact, it might be the most important attribute of an issue aside from the summary. It’s essential that we crisply communicate what the status is of each and every issue.

Status icons

We heard a lot about our status icons. You know the ones…

Quick test: Do you know the default meaning of each of these icons?  As a former JIRA administrator myself, I found it hard to find the right icon that would symbolize a consistent meaning across my organization. Users would often ask me what each icon meant. When we were using JIRA to track inventory, the people icons didn’t make sense. Additionally I’d often have to hunt for icons to represent new status. I’d ask myself, “Where am I going to find an icon to represent code review?” I found out that I’m not alone; lots of teams felt this way. So we’re making the status experience much better. With the next release of JIRA, the status attribute will now be ADG compliant.

From icons to lozenges

What’s a lozenge? Let’s take a look at what the ADG has to say:

Lozenges are used to highlight the state or status of an entity for quick recognition by users.

Our former solution with icons didn’t do either of those particularly well, so JIRA is moving away from status icons to using status lozenges. We’re also packing in more information while communicating status. We believe that all issues in JIRA go through three major phases: new (blue), in progress (yellow), and complete (green). Each status defined in JIRA will be in one of these phases.

The color of the status lozenge quickly communicates what phase of work this issue is in. We realize that every workflow isn’t three steps, of course – software teams might use a set of statuses to manage their workflow.

Our status lozenges have two rendering styles:

When scanning lists of issues, status is a part of the search results, but it’s not the only part. We use outline style in areas of the product where the traditional style is too distracting.  Outline style helps status fit in with the rest of the data in list view while giving you important information on your issues. We’ve also added tool tips to pull in the status description.

JIRA has also added a new compact view that shows status for sub-tasks in the issue detail view and in JIRA Agile. Hovering over the colored square shows the status name.

Use JIRA Agile? As of version 6.3.5 JIRA Agile uses the blue color to note work that has not started. You will see the new color in the sprint health gadget, plan mode, and work mode.

Lozenges localize too!

The new status lozenges also work well for JIRA in non-English-speaking locales. Users will be able to translate custom statuses. Let’s take a look at the status “open” in English, German, and Japanese.

Based on your feedback, we believe this change will make for a more consistent and effective experience with JIRA. Users in all locales will get contextually relevant information on the status of their issue. We will be rolling this change out to all applications that surface JIRA issues: The JIRA issues macro in Confluence, JIRA Agile, and integration with the developer tools will now sport the new ADG-compliant status lozenges.

The post ADG-ifying the way JIRA communicates an issue’s status appeared first on Atlassian Blogs.

Atlassian Summit was a while ago already. It was during the event that I presented a way to implement the Scaled Agile Framework in JIRA. The full video of my talk can be found in the Atlassian Summit archives.

During my Summit talk, I discussed three enterprise challenges when scaling Agile; process and documentation culture, underestimation of planning effort, and managing a complicated infrastructure. There certainly is a lot to say on all three topics!

In this blog post, I would like to dive a bit deeper into the planning effort when scaling agile and how to track progress by using Atlassian JIRA.

As one of the few official Atlassian Enterprise Experts, we are often asked to help set up JIRA for Enterprise customers. The initial request is almost always to help them get started with JIRA Agile in order to support their Scrum teams. But Scrum only covers the development teams, not the rest of the organization. Almost always, one or more of the following questions pop up:

• How do I plan work across multiple teams?
• As a project manager/product manager/business manager, I want to track overall progress. How can I do that?
• Before the Scrum teams can start working I need to do some analysis up front. How can I track and plan that?

Although every situation is different and every implementation is different, all of the questions above can be addressed by using the Scaled Agile Framework (SAFe) as the guideline for our advise.

3 levels of planning and tracking

The SAFe framework discusses three levels of planning: portfolio level, program level, and team level. Each level has its own items for tracking: needs on portfolio level, epics on program level and stories on team level. The SAFe framework has many elements that are very important but in this post I want to focus on just the three levels of planning and tracking and how to visualize them in JIRA. The image on the right serves as a visualization for the context of this talk.

Portfolio level

The portfolio level is the highest level of planning and tracking. This is implemented in JIRA with a single project. This project is configured with an issue type scheme that contains two issue types: business need and architectural need. Optionally you can add the type investment theme to reflect investments based on your corporate strategy.

Also create an issue link type named Implementation that configures a relationship between two issue types called implements and is implemented by.

On the portfolio level, portfolio items are managed according to a portfolio management process or project portfolio management process. This process should be reflected in a workflow that is assigned to the portfolio issue types and the portfolio project. You can visualize this workflow with a kanban board which is ideal to track progress of the portfolio items.

Program level

While the items on the portfolio level are put on a global roadmap that is planned for the coming year, analysis on the portfolio will result in epics that are placed on the projects, in the program level.

Epics typically belong to a system or a business service. Therefore the JIRA projects on the program level should follow this enterprise architecture of systems or services. I explicitly say JIRA project here to refer to the JIRA term of storing issues together in one container (another blogpost explains why the term project in JIRA is not so useful anymore.)

A JIRA project on the program level can contain epics, stories, tasks (e.g. refactor task or design task), and sub-tasks.

Team level

On the team level, the scrum teams plan their sprints with stories, tasks, and other work items. The easiest way to do that is with a JIRA Agile scrum board. The items on the sprint backlog are not limited to user stories only. Therefore estimation should not be limited to user stories either. By default JIRA Agile is configured with the Story Points field bound to only stories. This must be changed.

Visual board on 3 levels in JIRA

All the agile teams should have their own scrum board. Although it is possible to have one scrum board for multiple teams, this is not advisable. When having one board for multiple teams and thus having multiple active sprints, the sprint velocity is also shared and compared against other teams. Comparing teams is like comparing apples and oranges.

Scrum teams do not necessarily have their own JIRA project but use a specific issue filter to show all the items on the backlog from the different program level JIRA projects.

Of course, each level follows its own process. But each level has an interaction with the next level, as can be seen in the image on the left. Teams in one level are not “stand alone,” but part of the bigger picture and part of the entire process.

Traceability

With the above setup of JIRA in larger organizations, it is possible to have full traceability from code to business needs on the portfolio level and back. Stories are linked to changes in the source code while they also link to an epic. Epics then implement a business need. But implementing agile at scale requires a complete package of tools. So to complete the package of JIRA and JIRA Agile, I would add Confluence (Atlassian’s enterprise wiki) and Stash (Enterprise Git repository manager) combined with a set of add-ons (see this post for an overview).

Traceability in JIRA

By completing the package, traceability can now be extended towards documentation and source code. All issue types (needs, epics, stories) can be linked to a Confluence page for documentation. Stories are linked to the source code through Git. With the new Confluence 5.4 it is now also possible to link Confluence pages directly to sprints, to document retrospectives, and to demo sessions.

So step by step, the Atlassian stack keeps improving the agile way of working. For organizations big or small!

What’s next?

This article was originally posted on the Avisi Blog. We’ll continue to check in with Sander and others for more ideas on scaling agile in the enterprise. You can also check out our website for more tips about doing agile right.

The post Scaling agile in the enterprise with SAFe and JIRA Agile appeared first on Atlassian Blogs.

Atlassian has a very prolific blogging schedule, which includes 12 different blog categories with unique owners, and dozens of authors scattered throughout the company. Today we’ll take a look at how the content manager uses JIRA and JIRA Agile to stay on top of everything.

Keeping pace with the blogging schedule is all about flow. The content team has a few key goals when releasing content to Atlassian Blogs:

• Keep a steady flow of content rolling out to the readers
• Ensure each blog gets reviewed for quality by the content team
• Schedule content for each blog to maximize readership

Many software development teams rely on JIRA Agile to help them manage their workload, but the content team has slightly different scheduling needs as the work is very date driven. It’s important that blogs.atlassian.com gets new content on a consistent schedule to keep readers coming back for more. With several blogs and even more authors, JIRA Agile helps keep the chaos in order.

Kanban: The art of flow

The content team needs to keep a steady stream of blog articles in all states so there is a consistent set of posts going out on schedule. If any particular state is starved for work, then the posting schedule is in jeopardy of falling behind. JIRA Agile’s kanban boards help set the content team up for success. Let’s look at three ways the content team uses JIRA Agile to manage the flow of content.

1. Scheduling with swimlanes

The content team needs to see work scheduled out by week. This helps them understand how related content fits together during any particular week. Swimlanes in JIRA Agile easily group work items together by using flexible JQL queries. Let’s take a look at the swimlane configuration:

2. Managing risk with card colors

JIRA Agile has three main facilities to filter data: swimlanes, card colors, and quick filters. I often strongly recommend that people use JIRA Agile’s filtering mechanisms on different attributes so that so that viewers get maximum flexibility with their data. However, in this case, scheduling is so important to the team that we’re also going to use card colors to track time.  The card color will represent how close a ticket is to its publish date.

Each ticket in JIRA represents a blog idea. The team has set up a custom field called “Publish date/time” to track when then blog article should go live on blogs.atlassian.com. As an article gets closer to the publish date, we need to raise visibility for that particular issues. Thus, the card color “warms” as it gets nearer to its publish date. If issues are orange or red on the left side of the board – which houses blog ideas that are not even started yet, much less ready to be edited or scheduled – those issues are likely not going to make their publish date.

JIRA Agile evaluates card colors first to last. The card color that evaluates to true first will become that card’s color. We’ll start with blog articles that are late and then work back in phases until we no longer want to color cards. Here’s how the team configures its card colors:

In JIRA Agile you can specify colors by two different means: using the UI, or via Hex color codes.  To make it easy, I’ve listed a set of HTML color codes below that gives six tiers to organize your issues.

You can fill in the above color codes in JIRA Agile using the highlighted screen below.

3. Organizing content with quick filters

Atlassian maintains twelve different blogs so readers can subscribe to their favorite content. Quick filters help us filter content so that it’s easy to see what’s coming up for JIRA, Confluence, Dev Tools, as well as things like general Atlassian news.

JQL knowledge is valuable because we can figure quick filters the same way as swimlanes and card colors. We have a custom field called “main subject” to track the focus of each blog entry.

Bringing it all together

What does this lead up to? The content team now has an easy to use agile board that shows them what’s important in their world. Let’s take a look at the completed agile board. I took this screenshot a couple of weeks ago so that I could show you “our view” as most of this content has already been published.

JIRA and JIRA Agile help bring structure and consistency to many organizations. Browse our list of customer case studies for interesting use cases our software.

Ready to get started? Start a 30-day OnDemand trial of JIRA Agile today!

Try JIRA Agile today

The post How we manage Atlassian blogging with JIRA Agile appeared first on Atlassian Blogs.

For many teams becoming agile is a journey, not a point-in-time transition. While many teams share similarities, each team is unique in its skills and relationships. In this article, I’d like to focus on teams that have different, specialized skill sets; teams that can benefit from capacity planning, which ensures that there is the right amount of work for each person in the iteration. Many of the concepts in this article are for organizations that push work to the team. As teams transition to agile, learning where and how the team spends time is important. They can then better educate the business on moving to a more agile pull model. We will start with optimizing your team, estimating and scheduling work, and learning how to make continuous improvement a part of the team culture.

Your team: Generalists or specialists?

When managers build teams they usually focus on teams with generalists, specialists or a mixture of both. Let’s start with a few key definitions:

• Generalist (n) – A person with a wide array of knowledge that can work on a number of interdisciplinary tasks.
• Specialist (n) – A person who has unique knowledge on the team relating to a particular job, area of study, etc.

Many agile concepts focus on teams composed of generalists. For instance, scrum focuses on the team commitment and rebalancing work to meet that commitment. If everyone has the same skill sets, the team can easily rebalance work to meet the sprint commitment.  What happens to teams that can’t rebalance work?  Capacity planning can help any team, but teams with specialists will benefit most. Capacity planning is ensuring that everyone on the team, particularly the specialists, have enough work for the entire iteration.

Estimation: Using science and art

All of capacity planning hinges on good estimation practices, since inaccurate estimates make scheduling almost impossible. Many teams estimate in days or hours when beginning the agile journey. Breaking user stories down into component tasks that last no more than 8 to 12 hours is a huge step forward in taming uncertainty. My focus here is to show how JIRA can help the team understand with time management and planning. Let’s look at a sample software engineering team with designers, different kinds of developers, test engineers, and engineering services. We want to ensure that everyone has enough to do for the whole iteration.

I’d focus on looking at the team as a collection of skill sets. When estimating in hours, I recommend no one take on more than 65 hours of work in a two-week sprint to allow for the cost of doing business. What’s the cost of doing business?

We all have email to follow up on, meetings to attend, and other recurring tasks. Filing tickets for this type of work is too much overhead, so I only plan 75 percent of any given iteration with task work. If we have more than one person with similar skills we manage capacity by skill set rather than person.

Execution: Making every hour count

You can’t improve your processes if you don’t measure them. To help teams keep track of time, JIRA supports a feature called time tracking, which allows teams to estimate work and log the amount of time spent on an issue into JIRA.  JIRA then aggregates that data in several useful reports. JIRA has a panel in the issue detail view that exposes time information.

Logged work, no additional time added to an issue.	Blue: The amount of time originally scoped for a task Orange: The amount of time remaining on the task. The team may change the estimate to account for additional work. Green: The amount of time currently logged on an issue.
The current estimate is now less than the original estimate. The task will likely finish ahead of schedule.	The current estimate is now more than the original estimate. The task will likely finish behind schedule.
This task has subtasks.  With the checkbox enabled, JIRA will aggregate all the time tracking data from subtasks.	JIRA will only show time tracking data from the current issue.

JIRA has a number of time tracking options. After working with a number of teams, I’ve included the ones I recommend most. Use hours as the default unit of measure as it makes the math easier working inside of smaller iterations.

Moving forward: Aggregating the work ahead

Now that the team has estimates on all their issues, the workload pie chart makes it easy to see how much work is on a particular person’s plate. The workload pie chart queries the estimate in each issue and puts the total in an easy-to-read chart. I’ve set up a dashboard showing the original iteration commitment and how it might look after a few days of work. Here we see that the team changed the estimates to reflect new information after working for a few days.

In this chart on the left, Max, a server engineer is just about at capacity for this iteration, while Jennifer, another server engineer, has some spare capacity. Since they have similar skill sets, we can easily reassign some work from Max to Jennifer. The chart on the left will remain static throughout the iteration so the team can see the original projection. As we learn more about the work in the iteration, we can rebalance the chart on the right as needed. Keeping a close eye on how work progresses gives the team and the project manager the ability to remain proactive.

We can also abstract how we assign out work. By using a custom field called team, we can tag all of the user stories that require server skills, web development skills, and the test skills. If we leave each of the stories unassigned until someone takes action, we can plan work more flexibly.

If we have five server engineers, we know the amount of work we can take in a particular sprint for that discipline cannot exceed 300 hours. In this case, rank becomes critically important. As team members complete tasks, they will take off the next most important task in the current iteration. That way, the team is always working on the highest value items. By combining individual silos into a larger set of work, we can deliver back to the customer more efficiently.  JIRA Agile’s agile boards can help keep the most important items in focus using ranking.

The workload pie chart can display work using a number of fields. Project managers can see work outstanding for a sprint, version, by client to just name a few.

Retrospectives: Make growing a priority

The retrospective is one of the most important pieces in agile methodology and team development at large. Retrospectives are where the team gets to learn and then ultimately grow. The time tracking report provides valuable information back to the team. The team can easily compare estimates with the actual time spent to improve the way they estimate work. Let’s take a look at an example:

The time tracking helps the team understand how work got done, and it gives everyone measurable results from the iteration that can then drive planning for the next iteration. For tasks where the estimate is very different than the actual, ask yourself a few important questions:

• Could I have broken this task down into smaller increments?
• What would have been most helpful to know in the beginning?
• Would there have been a way to parallelize the work?

The Atlassian Marketplace has a number of add-ons to help teams track time.  Tempo and Folio extend JIRA’s feature set for deep business intelligence features on capacity, resource, and cost analysis.

Ready to learn more?  Try a 30-day OnDemand trial of JIRA today!

Free 30-day trial

The post HowTo: Capacity planning with JIRA appeared first on Atlassian Blogs.

Information is power. When everyone’s priorities are clear, we can make better decisions for our project and the organization as a whole.  Once upon an time at an old job, I needed a considerable amount of the IT group’s time to help me get a new CRM server up and running for my project. I often got the answer: “Wait.” but I never knew why. Deadlines were looming, and it was becoming hard to explain to my stakeholders why things were delayed. I didn’t know what priorities were trumping me, or if I could work with those parties in a more symbiotic fashion. What I did know was that there had to be a better answer than “wait.”

“Why can’t that team deliver when I need them to?!”

At least once in our career we’ve each struggled to work well with other teams. We lovingly refer to this as external collaboration tension. When your team relies on help from an external team, challenges arise, because each team has unique motivations and a myriad of tasks to accomplish. One of the main difficulties in working with an external team is a lack of visibility into what they have on their plate. When we don’t have context, we tend to assume that our requests are the most important in the other team’s workload. As a result, you not only place undue pressure on the other team, but also makes things harder for you. Since we’ve all been there before, in this article we’ll take a look at some ways to make working with external teams easier and more efficient.

Develop empathy through visibility

Teams never live in isolation. When we understand how teams depend on one another, it gives us the right context to work with others. Visibility to the other team’s workload gives us empathy and context into the other team.  The great news is that JIRA is designed to make things better – much better.  JIRA makes it easy to see what work an external team has on their plate, and where your particular task may be in their backlog. JIRA’s flexible permission controls make it easy to give all stakeholders permissions into the workload, velocity, and delivery of work. If I know who is ahead of me in the team’s queue, I’m empowered to have the right conversations to make my life and their lives better.

Let’s dig in to how we can configure JIRA to gain better visibility.

1. Utilize JIRA projects

Projects in JIRA are the building blocks of collaborative work. A project is much more than just a collection of issues; it embodies a team’s style of work through people, roles, workflows, issue types, custom fields, and permission schemes. Newer JIRA administrators often ask:

• How should I create JIRA projects?
• Do I create one big project for my company?
• Do I create many small projects?

I always give the same advice: Teams of people deliver streams of work back to their customers, and JIRA projects follow streams of work. In every organization there is a natural view of seeing which groups of people are responsible for a stream of work. Create a JIRA project for each team and its area of ownership, and when the stream of work significantly changes, create a new JIRA project.

2. Define participants and stakeholders

Now that we have a project in JIRA, we can begin to open it up to all of our stakeholders. In each project there are at least two types of users: participants and stakeholders. Participants are the people who are intimately involved in the project, submitting issues and participating in the resolution of those issues. Stakeholders are a step removed, because they may submit issues, but they never participate in resolving them. Understanding how to manage your stakeholders is an important part of project management. By default, JIRA has two user groups that help manage participants and stakeholders: developers and users.

Understanding developers vs. users

Out of the box, JIRA has two major permission roles: JIRA developers and JIRA users. What is the difference? JIRA developers are participants who can interact with issues in a particular project. (Note: They don’t have to be actual software developers. Many non-software teams use JIRA.) JIRA users can only file and see issues. JIRA users are the stakeholders who follow your project.

Using roles in JIRA

Roles are a flexible feature of JIRA that make giving permissions much easier. How does a role differ from a group? A group is a specific set of people that might be a specific team (iOS development), a department (engineering), or even a company’s full-time employees.

Roles are slightly different, as they represent functions in a project. Some software teams like to have the quality assurance team review all the changes from the development team. Those teams will have a role called quality assurance, and they can then change which members are part of that role for each project. By default there are two roles in each project that we can use: JIRA developers and JIRA users. Place the participants and stakeholders in each group.

In this example we have tis-developers as the group who are participants in the project. The stakeholders are in the group tis-users. JIRA’s flexible roles allow permissions to easily scale across multiple projects.

3. Make work visible

I can remember sitting at the DMV a couple of weeks ago waiting to renew my driver’s license. When I came in to the waiting room I was issued a ticket. Fortunately, I knew where I was in line but I didn’t understand how much work was ahead of me. All I could hear were numbers being called out. Sometimes the line would move quickly, and other times it would seem to be stuck forever. Work among teams can be very similar;  it’s frustrating not knowing the distance between you and the solution.

To make matters more challenging, discussions about priorities assigned to work don’t always happen with the right people. People often approach the team that does the work to see if they can reorganize other priorities. The problem is, they’ve got a set of commitments to other teams they need to balance. It’s much more effective to engage with those who have requested ahead of you to see if they can accommodate your schedule. Having those discussions beforehand significantly eases the tension on the shared team as they aren’t the decision makers.

Fortunately, JIRA Agile is a powerful way to visualize work for any team. People on teams that act as shared resources can use JIRA Agile not only to manage work, but also to broadcast priorities to the rest of the organization. JIRA Agile’s kanban boards are an excellent way to show the current status of all work ahead of the team.

Information is what empowers people to make effective decisions. When everyone in the organization has the same view it’s easier to prioritize, collaborate, and deliver.

Ready to try JIRA Agile today? Get started with a free trial of JIRA Agile OnDemand today!

Try JIRA Agile today

The post 3 steps to ease external collaboration tension appeared first on Atlassian Blogs.

There are no right answers when it comes to how teams plan, build, and launch great software. Every team and situation is different, making your process inherently different as well. The title of this webinar series might be a little misleading because there isn’t one way or a best way to do agile. The agile methodology provides a number of guiding principles and strategies, but leaves the implementation up to the team. Agile is a philosophy, not a rigid protocol. It’s designed to allow each team to optimize as necessary while following agile’s key tenets.

Do Agile Right webinar series

Join us for three 30-minute presentation with real Atlassians

What we strive to show in this webinar series is how our product management, development, and marketing teams do agile at Atlassian. Our teams have evolved and innovated throughout the years, and identified a number of best practices along the way. We want to share our learnings with you.

We hope this is a great opportunity for you, our customers, to learn how our product managers, developers, and marketers leverage the power of JIRA, JIRA Agile, and Confluence to employ agile methodologies to plan, build, and launch better software. Registration is limited, so sign up today!

Lessons learned from an Atlassian product manager

Tuesday, January 28th, 2014 at 11:00AM PST

Join two Confluence product managers, Sherif Mansour and John Masson, for a live 30-minute presentation about their agile best practices for successful product management.

Learn more and register now

Lessons learned from an Atlassian software engineer

Tuesday, February 11th, 2014 at 11:00AM PST

Join Edith Tom, Confluence developer, and Anatoli Kazatchkov, Confluence team lead, for a live 30-minute presentation about their best practices for successful agile software development.

Learn more and register now

Lessons learned from an Atlassian marketing manager

Tuesday, February 25th, 2014 at 8:00AM PST

Join Matt Hodges, product marketing manager, and John Wetenhall, associate product marketing manager, for a live, 30 minute presentation about their agile best practices for planning and launching software releases and marketing campaigns.

Learn more and register now

The post Join us for the Do Agile Right webinar series appeared first on Atlassian Blogs.

Agile teams are structurally different than their waterfall counterparts. Agile teams focus on the team itself, where waterfall teams often follow the structure of the organization. In traditional waterfall development scheduling often is “top down,” meaning management sets the pace and schedule. In agile, the team is self organizing, and sets its own schedule and destiny within the larger organization. As I was learning scrum one of the questions that kept coming to mind was, “How do development managers and scrum masters share responsibilities in the team?” In this piece I’ll explore the answer to this question.

Waterfall teams vs. scrum teams

Most waterfall teams are manager centric. They look to the the manager to set priorities, track progress, and evaluate performance. Agile teams are self-organizing, and  work with a product owner who sets the vision for what should be built, and is not usually in the management chain of the team. The team, through a series of sprints, drives how the product should be built.

Self-organizing teams own their destiny. In sprint planning they decide how much work to commit to the sprint, and because of that their level of ownership in the success of the program remains high. Engineers who own their own schedules build products of higher quality more consistently because they own their schedules. Engineers want to build high quality products on time, because everyone in the organization has the same goal. Tuckman’s stages of group development outlines how teams form and thrive. Self-organizing teams are no exception.

Mutual trust and candor are essential to well-performing agile teams. Management that continually focuses on hiring the right team is able to trust the team to get the job done. The need then to micromanage every detail of the team’s work becomes vastly reduced. The scrum master and the development manager then protect the team from outside distractions such as feature creep, waterfall anti-patterns, cross functional thrash, or side projects that will compromise the integrity of the sprint.

Role 1: Scrum masters

Scrum masters are the project leaders in agile teams who focus on optimizing performance of the scrum. Scrum masters work between the product owner and the team ensuring consistent, successful sprints by running stand-ups, and working to reduce blocking issues for the team. Cross-functional thrashing can be costly for teams, so successful scrum masters own cross-team coordination so the core team can focus on product development. This practice keeps everyone efficient and on the same page.

The scrum master coordinates most of the inputs and outputs required for an agile program. He or she drives the sprint kickoff, daily stand-ups, sprint review, and sprint retrospective. The scrum master is also an agile coach, helping the team to adopt and own agile practices throughout the product life cycle: story point estimation, sprint planning, and continuous delivery. The coaching aspect of the scrum master’s job is critical; He or she not only helps the team to be agile, but advocates for agile development throughout the organization, and spreads the good word about why agile development is right for the project and the company. Often times when agile methodologies are new at a company, the advisers and stakeholders outside of the team need agile coaching as well.

The scrum master works with the team and the development manager to estimate items in the backlog. At first, the team will need some guidance from the scrum master and development manager. As the team is forming it builds shared knowledge of the program through successful sprint planning. As the team moves into a performing stage the scrum master focuses less on estimation and more on optimizing the velocity of delivery.

Role 2: Development managers

There’s a lot of uncertainty for engineering managers when their team goes agile – an Admiral Stockdale moment, if you will. But despite the fact that agile development teams don’t rely on their manager for estimation and prioritization, managers still play a vital role.

Hiring well

The most important thing a development manager does is hire. You bring excellent people onboard and develop them within your team, everyone has the potential to bring significant value to your program. Why spend so much time on hiring the right candidate? Team changes are expensive on two levels:

• Searching for candidates takes focus away from building great product.
• When a new employees join, the existing team needs to spend time on-boarding them. Teams will experience a drop in velocity over a few sprints as each new person integrates into the team.

When a team is truly self organizing and performing well, everyone in the organization sees it through product quality and delivery. No one has more impact here than the development manager.

One of the big differences between agile and waterfall teams is that the development manager is a partner in the estimation process. In a waterfall team, a conversation like this wouldn’t be unheard of:

• “Hey, how long is it going to take to deliver this feature?” – Manager
• “It’s going to take six weeks. We need to do A, B, C to get the feature to market.” – Engineer
• “Hmm. That makes sense. However, you need to find a way to get it done in four weeks.” – Manager

But an agile development manager knows to hire great people, then trust them. One of the fundamental tenets of agile process are that those closest to the work are best able to scope and deliver. The team sets the schedule. The development manager adds unique value in inquiring and vetting assumptions made in the estimation exercise – partnering in the process, rather than dictating it.

Developing well

While scrum masters focus on team velocity, development managers build up team members’ velocity by coaching individuals one on one. Development managers curate and inspire great talent in their organizations. Great managers are adept at the fundamentals of management: One on ones, giving feedback, and coaching their teams. Successful development managers mentor engineers to bring greatness to the table: ideas, code, tests, and culture. Great development managers partner with their teams. At times, the team will struggle or come to an impasse with architecture design decisions. Adept development managers know when to intervene to break the impasse or let the team continue to struggle to grow the team. The scrum master may not be as technical as the rest of the team – the development manager lends valuable context between the scrum master and the team when there is a clear knowledge gap.

In addition, they also partner with the senior developers in the company to set the development culture. They are often influential in the technology choice for the program, and continue to own responsibility for the quality of the product  from the code architecture to the end-user experience. Development managers engage in code reviews to ensure team members are contributing code that meets the short and long term goals of the program. They also set context internally for the team and in the larger organization.

To learn more

We’ve spent a fair amount of time looking at what makes a great manager in an agile culture. For more information on how you can go agile, take a look at Do Agile Right at Atlassian.

The post Who’s who in agile teams? appeared first on Atlassian Blogs.

We’ve been using Confluence Questions for a few months now and we’re loving it. It’s simple – you ask a question, and you get answers. Questions like this one from our head of brand, Carilu Dietrich:

Personal productivity is a topic I’m particularly interested in and one I’ve blogged about before, so naturally I felt inclined to share my own approach. It has since become the top voted answer to Carilu’s question, which got me thinking there might be some value in my answer to folks that don’t work at Atlassian.

My four-step plan to managing email and tasks

I think everyone has their own approach to dealing with personal tasks that works for them. Here’s what works for me – hopefully there’s some tips in here that will work for you too.

For me, tasks arrive in one of four ways, and I have different methods of managing each of them.

1. For content in Confluence or JIRA that requires my input, I use Confluence WorkBox

Since my team creates and shares everything in Confluence or JIRA I’m often asked to review content – draft blog posts, project plans, email copy, etc. – via @mentions or Shares. When I’m at work I’ll check my notifications in WorkBox a few times throughout the day. If I’m not at my desk I can also check my notifications via Confluence Mobile.

If there are notifications that require an action from me I’ll either do it straight away if it’s something I can do in under two minutes – e.g. a replying to a comment or liking a comment – or I’ll create a task in Workbox for things that will require more time – e.g. reviewing a draft blog post or copy for an outgoing email.

Here’s an example of a JIRA notification from which I have created a WorkBox task. Note, this is not a JIRA issue that has been assigned to me, just one that requires my input:

I’ll run through and complete my WorkBox tasks once a week or so. If something needs to be done urgently or ASAP and I haven’t gotten to it yet, I rely on whoever is asking me to nag me to complete it.

Here’s a quick video that shows how you can use Workbox in Confluence:

 Pro tip: How to avoid notification email overload

Since I exclusively use WorkBox to track notifications from Confluence and JIRA that require my attention, I have created a set of filters in Gmail so that all email notifications that I already see in WorkBox – e.g. replies to comments and likes – just skip my inbox and are marked as read.

For notifications that don’t show up in WorkBox – e.g. notifications for all new blog posts – I have a filter that allows the message to skip my inbox but remean unread. I also have all page/blog/comment edit notifications automatically skip my inbox and marked as read.

2. For tasks that I need to complete in a sprint, I use JIRA Agile

My team practices scrum and we run bi-weekly sprints to make progress against our quarterly goals. All tasks (stories) that I have committed to completing in our sprint planning meeting are tracked in JIRA Agile on my team’s rapid board.

3. For tasks from email, I use Gmail stars

Fortunately I don’t get a ton of work-related email since most of my work takes place in JIRA or Confluence, and I use WorkBox for managing those notifications and any resulting tasks as described above. Additionally, I don’t do a lot of work with people outside of Atlassian. With this in mind, here’s my method for managing my email:

1. Read

I force myself to only check my email a couple of times a day when I have 15-30 mins to plough through my inbox. Sometimes I will even ignore requests I get via email. If it is important enough, the requester will send me another email and that’s when I will deal with it.

2. Act

If the email requires action and can be done in under two minutes, I deal with it there and then (e.g. reply or forward). If it’s going to take significantly more time to deal with, I will star the email as a reminder to get back to it later and then archive it.

I like to keep my inbox clear so every email is archived once I have read it.

3. Review

When I have more time, usually in the late afternoon, I will review my list of starred emails and deal with them based on which I deem to be the most important. If something is urgent, people have other means of contacting you to get a repsonse e.g. HipChat, phone, or in person.

 Pro tip: Become a Gmail Ninja

4. For all other tasks, I use Any.do

Sometimes there are tasks that don’t come from a task in Confluence, JIRA, or an email. They are just things that pop up that need to be done – personal or work. JIRA is too heavyweight to track them, and you don’t want to forget them. That’s why I use Any.do.

Any.do is a simple and free task management app for iOS, Android, and the web. Tasks are synced across all your devices and they have a handy Chrome extension, too.

 Pro tip: At the start of each day, write down the one to three things you want to get done and cross them off as you complete them.

On a related note, I’ve just started using Simplenote for taking ad-hoc notes and also jotting down things that I want to discuss with my team in our 1:1′s. Evernote has never really worked for me, and this seems to be a simpler app and a good solution that works and syncs cross platform.

That’s it. It’s not rocket science, but it works for me.

How do you manage email and tasks?

I’m always looking to improve my personal productivity and would love to learn what works for you. Comment away.

The post I am Matt Hodges and this is how I manage email and tasks appeared first on Atlassian Blogs.

Yesterday, two of our very own Atlassian Confluence product managers, Sherif Mansour and John Masson, hosted a live webinar where they shared agile best practices that they’ve learned over the years, including:

• When to write product requirements documents and when to seek alternatives
• How to write effective product requirements documents
• How to build prototypes when designing new features
• Using JIRA and Confluence for product management

You were clearly eager to learn

We reached GoToWebinar’s 1,000 attendee-limit in the first five minutes! Sorry to all those of you that did register, but missed out on attending. We’ve put measures in place to ensure this doesn’t happen again for future webinars – we were simply overwhelmed (and chuffed) with your eagerness to learn how to do agile right.

Watch the recording, share it with your team

If you’re interested in product management and agile, this webinar is must see. Enjoy!

Additional Resources

Upcoming webinars

We’re not done yet! Yesterday’s webinar was the first in a three-part webinar series about how Atlassian teams do agile. Check out the next two upcoming webinars with members from the Confluence development and marketing teams.

Lessons learned from an Atlassian software engineer (Registration closed)

Tuesday, February 11th, 2014 at 11:00AM PST

Registration for this webinar is full. A recording will be available on this blog following the webinar.

Lessons learned from an Atlassian marketing manager

Tuesday, February 25th, 2014 at 8:00AM PST

Join Matt Hodges, product marketing manager, and John Wetenhall, associate product marketing manager, for a live 30-minute presentation about their agile best practices for planning and launching software releases and marketing campaigns.

Learn more and register now

The post Watch the Do Agile Right webinar – Lessons learned from an Atlassian product manager appeared first on Atlassian Blogs.

project=myproject and resolution is empty and 
“story points” > (what is considered large at your company)

The post Evaluating JIRA Agile – Product Owners appeared first on Atlassian Blogs.

The post Evaluating JIRA Agile – Scrum masters appeared first on Atlassian Blogs.

Try JIRA Agile

The post Evaluating JIRA Agile – Team members appeared first on Atlassian Blogs.

We say that Confluence Team Calendars is your team’s single source of truth for managing team leave, tracking JIRA projects, and planning events. The introduction of event types in Team Calendars 4.0 made this easier than ever – see exactly what you want, and hide what you don’t. In this post, I’ll share how Team Calendars helps the collaboration marketing team align our team, projects, and events.

1. Aligning our team

One of the perks of working for Atlassian in San Francisco is our new Vacay your way policy whereby staff in San Francisco no longer accrue vacation or sick leave, but rather can take as much leave as they like (as negotiated with their manager). This means we no longer use a formal HR tool to track leave; but as a manager of a team of five, I still needed a way to track and visualize my team’s vacation and travel plans against our planned marketing activities. Enter Team Calendars.

Tracking team leave

Once I approve leave, it is added to our team’s calendar using the Leave event type. Seeing everyone’s planned leave in a single view is especially useful for me as a manager as I can ensure I don’t grant vacation to everyone at the same time.

Share scheduled travel

As a globally distributed company with offices in San Francisco, Sydney, Amsterdam, and Tokyo there’s usually always someone traveling to another office to spend some valuable face-to-face time with other cross-functional teams like product management and development. Additionally, we sponsor and exhibit at a number of conferences and events around the world. Thanks to team calendars it’s easy for us to know who’s where, and when.

Approving leave and travel

Since we no longer accrue time off, there’s no need to use a formal HR system to track leave and vacation. All we need is a way for staff to request approval for time off from their managers – that’s where JIRA Service Desk comes in.

In addition to being a powerful and intuitive solution for your internal service desk needs, JIRA Service Desk is flexible enough to handle any type of request. Our Experience Team created their own service desk to handle employee kudos requests, and now managers are starting to use it to handle leave requests.

We’re in the middle of rolling out this process, and once it’s fully implemented we’ll be able to completely automate the display of our team’s leave and travel. Team Calendars’ support for displaying JIRA issues on a team calendar based on any date field, including displaying issues by date range, makes this possible.

Look out for a more in-depth post in the coming weeks on how to setup Confluence Team Calendars and JIRA Service Desk for tracking your team’s travel and leave.

2. Aligning our projects with Team Calendars and JIRA Agile

For my team, a project is usually in the form of a marketing campaign, product launch, event sponsorship, or webinar. Whether it’s the launch of a major product release like Confluence 5.4 or a campaign like the currently running Do Agile Right webinar series, we track all our team’s projects in JIRA and communicate when they’re happening to the rest of the business in Confluence using Team Calendars.

Tracking product launches, campaigns, and webinars

For every one of our projects we have a corresponding issue in JIRA (bigger projects are created as epics in JIRA Agile). We use Team Calendars to visualize when each project is due using the JIRA Issue Dates event type which allows you to display issues on a calendar based on their due date field in JIRA. This is both our single source, and the rest of the businesses’, single source of truth for when a launch, webinar, or campaign is scheduled to be announced or take place.

Display exactly what you want with JQL

With multiple types of projects – launches, campaigns, webinars, event sponsorship, etc. – and two products that make up Atlassian’s collaboration portfolio – Confluence and HipChat – we needed a way to distinguish between each type of project, by each product. Since we use a single JIRA project across all of Atlassian’s marketing department, and we didn’t want to create new issue types to represent each type of project, we used a combination of JIRA components:

Components for products

• Confluence Marketing
• HipChat Marketing

Components for project types

• Launch
• Webinar
• Project
• Event Sponsorship

Below is a JIRA issue we are using to track one of the webinars in our Do Agile Right webinar series – notice its components.

Using JIRA Query Language, we’re then able to create a JIRA Issue Dates event type in Team Calendars for each project type, for each product – for example, Confluence Webinars:

The JQL being used to create this event type is as follows:

Scheduling outgoing emails and managing your blogging calendar

Like most marketing teams, we write a lot of blog posts and use email as a primary means of communicating with our customers. With Atlassian’s portfolio of products continuing to grow, so are the number of blog posts we publish, and emails we send. Thankfully, we’re able to use Team Calendars to schedule all outgoing emails and blog posts to make sure we’re not doing too much at once and bombarding our customers with messages.

Since we have dedicated teams who manage our email communications and public blog we make use of JIRA issue types so that both outgoing emails and blog posts can each go through their own custom JIRA workflow. For example, below is the JIRA workflow that blog posts go through before they are eventually published on our site.

Just like our marketing projects, we make use of the JIRA Issue Dates event type in Team Calendars and use JQL to create specific Team Calendars event types for each of the following:

• Confluence Blogs
• HipChat Blogs
• Confluence Emails
• HipChat Emails

The JQL being used to create this event type is as follows:

Bringing it all together

The beauty of Team Calendars is that you can view your team’s planned leave and vacation, alongside your scheduled marketing projects, blogs, and emails in one single view. If there’s a conflict (perhaps someone is on vacation when they are supposed to write a blog post) or a product launch date slips (the development team hits a blocker), it’s easy to identify them in advance before they become an issue and reschedule using drag and drop. It’s that easy.

Make Team Calendars your team’s single source of truth today

Learn more about Team Calendars and see how it can become your team’s single source of truth for managing team leave, tracking JIRA projects, and planning events by starting a free 30-day trial today.

Learn more

Join us online to learn more

If you’re interested in learning more about how my team uses Confluence, JIRA Agile, and Team Calendars, join us for our live webinar, Do Agile Right: Lessons learned from an Atlassian marketing manager, on Tuesday February 25th at 8AM PST.

Register now

The post Inside Atlassian: How I keep my team aligned with Team Calendars appeared first on Atlassian Blogs.

Yesterday, two of our very own Atlassian Confluence developers, Anatoli Kazatchkov and Edith Tom, hosted a live webinar sharing agile best practices for software development that they’ve learned over the years. They talked about:

• Spiking new features and running shorter sprints
• Running frequent demos, dogfooding, and shipping frequently
• Empowering developers, open communication, and continuous improvement
• Using JIRA and Confluence for Agile software development

The webinar was a huge success for the team – It was the first ever hosted by the Confluence development team, and over 900 people attended!

Watch the recording, share it with your team

If you’re interested in agile software development or how Atlassian builds software, this webinar is must see. Enjoy!

Do Agile Right webinar series

We’re not done yet! Yesterday’s webinar was the second in a three-part webinar series about how Atlassian teams do agile. Check out the upcoming webinar with members from the Confluence marketing team.

Lessons learned from an Atlassian marketing manager

Tuesday, February 25th, 2014 at 8:00AM PST

Join Matt Hodges, product marketing manager, and John Wetenhall, associate product marketing manager, for our next live, 30-minute presentation. They’ll cover their agile best practices for planning and launching software releases, and marketing campaigns.

Learn more and register now

Lessons learned from an Atlassian product manager

Atlassian Confluence product managers, Sherif Mansour and John Masson, share the Agile best practices that they’ve learned over the years, including:

• When to write product requirements documents and when to seek alternatives
• How to write effective product requirements documents
• How to build prototypes when designing new features
• Using JIRA and Confluence for product management

If you’re interested in product management and agile, this webinar is yet another must see.

Agile best practices powered by Atlassian tools

Software development tools don’t  automatically make for Agile best practices, but they can help a lot. Our product managers and developers  make extensive use of the integrations between JIRA and Confluence. Here’s a quick video that shows off what’s capable:

The post Watch the Do Agile Right webinar – Lessons learned from an Atlassian software engineer appeared first on Atlassian Blogs.

Three weeks ago two of our very own Atlassian Confluence product managers, Sherif Mansour and John Masson, hosted a live webinar sharing Agile best practices that they’ve learned over the years, including:

• When to write product requirements documents, and when to seek alternatives
• How to write effective product requirements documents
• How to build prototypes when designing new features
• Using JIRA and Confluence for product management

Want to watch? Just scroll to the bottom of this post.

You were clearly eager to learn

At the time, we reached GoToWebinar’s 1,000-attendee limit in the first five minutes! Many people who wanted to attend were blocked from the webinar.

To make up for wasting their time, we hosted a second webinar, Q&A style. John and Sherif took another hour to answer popular questions from the first webinar, and take additional questions from the new attendees. The results were awesome and very informative!

Watch the recording, share it with your team

If you’re interested in product management and agile, this webinar is must see. Enjoy!

Do Agile Right webinar series

We’re not done yet! We’ve already hosted our product management and software development webinars, but check out the upcoming webinar with members from the Confluence marketing team.

Lessons learned from an Atlassian marketing manager

Tuesday, February 25th, 2014 at 8:00AM PST

Join Matt Hodges, product marketing manager, and John Wetenhall, associate product marketing manager, for a live 30-minute presentation about their agile best practices for planning and launching software releases and marketing campaigns.

Learn more and register now

Lessons learned from an Atlassian product manager

Watch Atlassian Confluence product managers, Sherif Mansour and John Masson, share their agile best practices:

The post Watch the Do Agile Right webinar – Q&A with Atlassian product managers appeared first on Atlassian Blogs.