14. If a major
project is truly
innovative, you
cannot possibly
know its exact
cost and its
exact schedule
at the beginning.
Joseph G. Gavin, Jr.
Designer, NASA Lunar Module
”
“
15. Individuals and interactions
over processes and tools
Working software over
comprehensive documentation
Customer collaboration over
contract negotiation
Responding to change over
following a plan
16. Individuals and interactions
over processes and tools
Working software over
comprehensive documentation
Customer collaboration over
contract negotiation
Responding to change over following a plan
17. • Popular tab
• Consistent gardening
• Internal marketing
New is a
constant
Application links are simply a way of telling Atlassian applications where other Atlassian applications live.
Just tell JIRA where other Atlassian applications live. Simple and easy, doesn’t have to be done in OnDemand
We’re going to talk about a bunch of integrations. All of these work thanks to Application Links.
Who in the room is a PM or equivalent.
How many people here
So, PMs are the guys who are there to drive the product. They fight for the user, curate the backlog, help others see the future of the product. They don’t have pictures because they’re not there yet, but they have ideas about what the future will look like.
Some people think they fight for the user. They garden the backlog, they tell us what users want form the product.
The CEO knows that they handed these guys the keys to the product so they go to them with ideas for where the product should go next.
So your PM lands on an idea and he wants to really get it rolling. Here is the biggest challenge that PMs face. The inability to see just how long it’s going to take, for that future in his mind, to become reality.
This problem is at the heart of agile software development.
This is the agile manifesto. It’s something a lot of Software teams believe in and something that Atlassian looks to for guidance.
*Go straight to respond to change*
44 comments, 104 likes
We’re starting work on what we’re sure will be the next big thing. We’re not entirely sure what it is yet though yet so we’ve called it Project Valkyrie.
Not the first big integration to talk about is that when you create this project in JIRA a space
Confluence turns copy and paste, an operation that everyone knows how to do, into real issue tracking.
This is the Project Valkyrie feedback page. It’s a place where we’ve been keeping track of all the feedback that’s come in about our internal version of Project Valkyrie.
Mike has mentioned an issue in feedback but hasn’t linked to a JIRA issue.
It turns out that I came across the same issue a few days ago and raised an issue which someone else is currently working. In order to let Mike know that an issue already exists, I’m going to go look that issue up quickly and link it in the Confluence page.
I’m just going to copy the URL of the JIRA issue.
Then I’m going to paste it inside the Confluence page. This automatically creates a JIRA issue link.
Now, I called this section: JIRA to Confluence and back, but it actually goes one step deeper. Because I’ve linked to this issue in Confluence, a link back to this Confluence page is also created inside of JIRA.
So now that I’ve created this link, anyone who is working inside either JIRA or Confluence can go and get more insight into the issue by navigating easily between Confluence, which contains softer communication about projects and JIRA where work is tracked in concrete terms.
Another great integration between Confluence and JIRA is the ability to create issues without ever leaving Confluence.
Helen is a BA at the company. She’s been using a preview version of Project Valkyrie for a few weeks.
One day Helen sends me a message in HipChat explaining a difficulty that she’s been having.
I go to our Project Valkyrie feedback page and edit it. I paste in Helen’s feedback.
Then I move over to the column where we normally link the JIRA issue. But wait a second, we don’t have a JIRA issue for this, Helen gave me this feedback over HipChat.
All I have to do is open the macro browser (you can do this via a keyboard shortcut, from the toolbar or by typing a curly brace) and choose to insert a JIRA issue.
This will open a dialog where you can create a new JIRA issue.
This creates a JIRA issue link straight from the editor.
From there we clean things up a bit by mentioning Helen and Alex to ensure they are both notified.
This has value to Helen because she knows that her ideas are being heard and responded to.
It’s valuable to our designer Alex because she knows that her work will help end users better understand the system
“Wired In” from the social network is a story telling mechanism to talk about how developers are most productive when they can focus for long periods of time.
I’m going to talk about how we try and enable developers to stay ‘in the zone’ for large periods of time by ensuring that their tooling is as focused as possible. The goal is to avoid context switches.
JIRA shows a lot of data.
We know that some users need this kind of context. They need to be able to see the whole backlog in order to prioritize the next month or six months of work.
But developers need to focus.
JIRA Agile’s rapid board allows a developer to see exactly what they need to work on next. They can transition issues efficiently (click and drag) and they can see the ordered backlog of work that’s ready to be worked on in a “To Do” column.
So how do we bring that same type of focus to our integrations.
By ensuring that a developer can perform the actions they need from where they are most comfortable.
If they use stash
Stash is a developer tool from Atlassian that does git workflow management.
This is a tool that I as a developer use every day at Atlassian for the project that I work on. Our team uses git to manage source code, stash is there to give us a view over top of GIT so that we can see who wants to add contribute code, what they are changing and gives us a place to discuss those changes.
Reiterate that our goal with these integrations is focus for the developer. We want to allow them to perform the actions they need to perform without interruptions and allow them to get the data they need with as little fuss as possible.
A “Pull Request” is a declaration by a member of the team that they would like their code to be pulled into the code base. Many teams throughout the world and indeed at Atlassian uses these as an opportunity to keep track of changes that are happening to the code. Here is an example of a pull request.
Describe.
Issue keys are automatically linked to the respective JIRA issues.
When you type an issue key into Stash, it automatically recognizes it.
And turns it into a JIRA issue key.
But remember, we just talked about how we wanted to keep friction and interrupts low so instead of that link taking the user away to JIRA, an unwanted context switch.
It sucks the data out of JRIA and displays it inside of Stash.
Note that these buttons also understand JIRA issue transitions and allow you do perform those transitions without leaving Stash. So if this PR moves the issue from “In Progress” to “Code Review”, you can do that without leaving Stash.
What about JIRA, where does it fit in with all of this?
I mentioned that for PMs visibility into what is getting done is key. How do we up level the information that’s created as a part of these commits happening in stash to those PMs?