Jump to content
Community Blogs
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
  • entries
    10
  • comments
    0
  • views
    396

About this blog

This is all about Atlassian. Jira Software, Jira Service Desk, Confluence, Stride,  Bitbucket, Bamboo, Sourcetree and even Trello and Statuspage. Information of the different systems as well as plugins and my best trick and tips.

Entries in this blog

Atlassian and Slack have forged a new strategic partnership

Atlassian and Slack have forged a new strategic partnership. They will discontinuing Hipchat and Stride, and are providing a migration path to Slack for all their customers. This is a huge step for Atlassian and it comes with some problems for companies that have decided against Slack as their team communication tool. The biggest issue some companies have regarding Slack is that it's not possible to host and develop for internally. The benefits should more than make up for that, especially in distributed development teams. Slack is by many, including me, considered to the standard for group communication for development teams. Not only are most companies using it, officially or unofficially, but many communities are also based on Slack these days. I find this move a bit surprising from Atlassians side, but I think if we can build upon the integrations a bit where needed it can be a really, really good move for both Atlassian and Slack.
  The Press release (https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership)  

JimiWikman

JimiWikman

Invision for Jira - a great way to add your design to Jira?

Invision is a popular tool for visual designers and UX designers, but it is usually a pain to transfer the information over to Jira. With Invision for Jira that becomes less problematic since you can embed an inline prototype directly into a Jira issue that also include the inspect function that makes life easier for the developers. While this is very nice, it really is just a fancy way to link people to Invision because the links will take you to Invision and you get the same issue with making sure everyone have a login and understand the way Invision works. This does not solve the actual problem to bring in the information the designers need into the documentation, it just add a more convenient way to direct the users to Invision. So this leaves the designs in Invision, which is not a good place to keep designs once they are agreed upon since you need to ensure the designs are not continuously improved as that cause issues with requirements. This can be solved by transferring projects to a another, controlled Invision instance, but that is messy and prone to confusion and mistakes. What I would like to have is a way to embed this directly into Confluence where it can be version handled and controlled from a requirements perspective. The concept is amazing, but the solution right now is not enough for a good way to bring in design in a controlled way as a requirement into Jira unfortunately.

JimiWikman

JimiWikman

Gliffy Projects for Jira - Get designs done right!

Gliffy Projects for Jira is another great product from the Gliffy Team and this time they help bridging the gap between design and development. It's an easy concept that is easily understood by the designers using hotspots in the design directly connected to development tasks. The concept is super easy and it is quite nice to be able to just add work tasks directly to a design the way Gliffy Projects do it. The down side however is that you need to use another image manager which is the Gliffy Projects. If I am already using Invision for example it does not really feel natural to add the images again to another tool just to create the hotspots to Jira. For this to be a slam dunk I would love to see it integrated in Confluence like their other products so I can stay in one tool for requirements and from there simply connect the uploaded designs in the same way. I do hope Gliffy are working on this because that would make this an invaluable tool in any project using visual design or workflows that need to be translated into activities.

JimiWikman

JimiWikman

Take control of your notifications in Jira with Announcer for Jira

Announcements in Jira is an important part of the Jira administrators job. The balance between being annoying and not keeping the users properly informed is a thin line indeed. While Jira provide email and banner options, its still a blunt tool to use and sometimes you even wish for your Jira Project Leaders to have the power to keep their projects informed. This is where Announcer for Jira can help. With it's flexible system it can inform users in many ways, including group selection, scheduled notifications, several types of notifications and more you can make your notifications as unobtrusive as your users need them to be. It's quite the tool to add to your arsenal of plugins and during upgrades and incidents your users will love you for giving them the power to be informed.  

JimiWikman

JimiWikman

The responsiblity of the Jira Project Lead (JPL)

Jira Introduction for Jira Project Leads Welcome Project lead, to a brief introduction to Jira and your responsibilities and options as Jira Project Leader (JPL). As JPL you are responsible for all activities within your projects. This includes all on-boarding and off-boarding processes as well as making sure your project is maintained in a way that ensures that no performance impacts can occur. As your responsibility is quite big, you are also eligible for training and support.    Responsibilities The JPL have full responsibility of his or her project. This means that anything happening within the project will fall on the JPL. This includes performance issues due to wrong setup or usage of fields, flows, boards and filters. It also includes on-boarding new users and of course off-boarding to ensure that no users that should no longer have project access still linger within your project. As the JPL you are also responsible for ensuring that your team or, teams, can work in an optimal way. This includes helping them to setup and operate boards, sprints and so on. You may not be the person who actually do this on a day to day basis, but you need to know how to support the members of your project should they need it.  You are also responsible to ensure that the project specific functions for versions and components are maintained correctly. That includes to archive versions no longer being used and ensure that the setup of components are used according to standards to allow for cross functionality and integration sanity.   Contact person The JPL is the first contact, and often only contact, when issues occur in Jira. As the contact person the JPL is required to be a member of the Jira Teams as well as keeping updated regarding news on the Jira SharePoint site. In the event of an issue with Jira as a whole, or even more important an issue with the project the JPL is responsible for the JPL should be able to respond within a reasonable time frame. Failure to respond could lead to a shutdown of the project. If a JPL is no longer active the project can be shut down until a JPL is assigned. This is because we cannot have a project without a responsible person owning it. A person must be contactable should anything happens that require action from the JPL.   On-boarding a Project On-boarding a project is done by making sure the correct setup has been added during creation. This is done by accessing the project settings and reviewing the settings. If the settings are not correct it could cause serious problems working in Jira for the whole team. During the project creation it is also up to the JPL to verify that the workflows and other settings are not only correct, but also suitable for the team to work with. If the way of working can benefit from customization than this can be discussed with the Jira team. Customizations are exceptions and require an obvious improvement to the workflows of the team.   Off-boarding a project When a project is no longer needed it need to be archived. This is done by sending a request to the Jira team. Doing this will make the project read only for a year and then hidden for a year before it is deleted. When a project is archived it will no longer show up in searches. All issues in the project will also be hidden from searches. This reduce the number of items that show up in searches, which in turn will reduce the number of items that need to be fetched from the database. This help performance and reduce clutter in Jira.   Handling Users Handling users is done by adding or removing users manually in the Roles section. When a user is added to the Jira project it is the responsibility of the JPL to ensure that the users have the knowledge and understanding of how to work in Jira. As the JPL this responsibility cannot be put of someone else and if a user cause incident in Jira due to not understanding the way of working or how Jira works, that is on the JPL. For this reason, it is suggested that new members get proper training within the project or by attending a Jira training session. Each user uses a license in Jira and as such it's very important to not let users accounts remain after they have left. It's the JPL who is responsible for keeping their members up to date as they also are responsible for the license cost of their project.   Handling versions Versions are important parts of Jira as it is the way we can determine in what code base development or configures has been committed. Version are created and managed by the JPL and project managers, which means that the responsibility with releasing and archiving versions also fall on the JPL. Once a version no longer is required to connect defects to that version should get closed. This is done by the JPL and the project managers. If this is not done properly the list of versions will grow exponentially, which causes issues for the project and potentially for Jira as a whole.   Handling Components Components are used for additional grouping for Jira issues within a project. While this is a very useful feature it's also important to remember that components are project specific and if you work cross projects then a moved issue can lose this information. It is the responsibility of the JPL and the project managers to manage the components and make sure it's used on a level that cannot be compromised if an issue moves to another project. For this reason, components should not contain issue critical information.   Performance impact decisions Decisions within the project, like adding new custom fields or values within a custom field, custom workflows or filters for boards also fall under the responsibility of the JPL. For this reason, it's important to understand the impact new fields, filters and so on have on the project as well as on Jira as a whole. Should a project become slow due to performance issues or worse, if all of Jira would suffer due to decisions that lead to performance issues, that is on the JPL. For this reason, it's no excuse to claim ignorance as failure in this regard can cause severe impact and possibly legal actions. As JPL it is strongly suggested to consult the Jira team if you wish to adjust your project that you are unsure if it can impact performance.   Expectations Day to Day operations The JPL should have knowledge on how to do the basic day to day operations. This includes creation of sprints, setting up boards, working with filters and backlogs as well as the JPL specific tasks of managing components and versions. The JPL are the owner of your project and as such the JPL should know how Jira works so they can guide the members of the project on a daily basis. The JPL are not expected to be an expert but should know the basics. For this reason, all JPL's should attend the JPL training before starting their project. It's also suggested to attend at least one JUT training session and all JST training available.   Possibilities While it might sound like a JPL have a lot of responsibilities they also have a lot of possibilities. Not only will the JPL have access to the JPL trainings, they also have the possibilities to request support and guidance from the Jira team.   Training Besides access to the JPL training sessions all JPL's have the option to request support from the Jira team for specific training sessions. This can be anything from an extra JUT session or it can be a full-fledged JST with custom content specifically designed for the need of the JPL and the project team. At any time can the JPL request assistance on Jira matters from the Jira team through Teams.   Jira Customization All projects are not equal, but in Jira they all follow the same structure. For this reason, it is sometimes necessary to make customizations to improve the quality of work or improve efficiency. The JPL can request a consultation with the Jira team to discuss a solution to achieve this that is best suited for the project as well as for the system as a whole. Common requests are custom fields to add more information inside Jira, custom workflows for situations when the standard flows no longer apply and custom screens for displaying certain type of information differently. Since these requests cause a strain on performance they need to be carefully considered and designed so they can be used by many and not be project unique only. All customizations must be requested by the JPL and it must be approved by the Jira team before it can be added to the system setup. Plugins Plugins is a special request that also can be initiated by the JPL, but as plugins have a much higher degree of maintenance it cannot be approved by the Jira team alone. All plugins follow the demand process where it will go through an approval board. It is up to the JPL to define why a plugin should be added to Jira and to secure the finances to pay for it.

Scaling Agile with JIRA Software & Portfolio

In 2015, ABN AMRO, one of the largest banks in the Netherlands, rolled out agile across their organization. Within a year and a half, ABN AMRO grew from over 100 to 7000 users, and they are now moving towards using JIRA Software Data Center. This growth greatly increased their system complexity, that included 65 administrators that had created over 65 issue types, 250 statuses, and 400 workflows. In this session, ABN AMRO will share the process of introducing scaled agile to their organization, which includes identifying the impact on usability, gathering metrics, and improving system performance and maintenance. You can also learn about how Portfolio for JIRA is an integral part of scaling agile across an organization and which best practices you can apply to your own journey.

Scaling Agile with Portfolio for Jira

It's no secret that scaling agile is a challenge both culturally and operationally. So, how do other companies do it? How do they achieve success and what do their journeys look like? Bree Davies, Portfolio for Jira Product Manager, will detail one such case study of how a large insurance company with 12 software teams collaborate, plan and track their work to deliver value to their customers continuously. You will hear about a company's transformation to scale agile and how tools such as Jira Software and Portfolio for Jira have been key to their operational and cultural success. Plus, you'll walk away with tips and tricks to use Portfolio for Jira efficiently for your own long term planning.

Jira Server 7.10 EAP has been released

We've just released a sample of Jira Server 7.10 as part of the Early Access Program (EAP) to let you know about the changes coming to Jira. Changes With this release, we're bringing the following improvements: New look and feel: We're updating the most frequently used pages in Jira, following the new Atlassian design direction. We've also changed typography, icons, colors, and made some smaller tweaks here and there. This is the first wave of changes, more will follow in the next releases. We hope you'll like it, we surely do! Support for IPv6: Jira is now supporting communication over IPv6. You can use it for all configuration that previously worked on IPv4, however there are some best practices and limitations you should read about. You can read more about these changes in the development guide for Jira Server EAP. For any questions you have, reach out to our developer community. Downloads We've prepared separate EAP Server downloads for Jira Core, Jira Software, and Jira Service Desk, so just pick your favorite here: Download the Jira 7.10 EAP. What's the deal with EAPs? EAP releases are early previews of Jira during development. We release these previews so that apps developers can see new features as they are developed and test their apps for compatibility with new APIs. The Jira Server 7.10 EAP is best explored hand-in-hand with the Preparing for Jira Server 7.10 development guide. The development guide contains all changes in Jira Server 7.10, and important new features that may affect app developers. If you discover a bug or have feedback on Jira Server 7.10, please let us know. Create an issue in the Jira project on jira.atlassian.com with the component Jira 7.10 EAP. Download the Jira 7.10 EAP

JimiWikman

JimiWikman

Atlassian Updates their Privacy Policy

Thanks for using Atlassian collaboration tools! We're constantly striving to provide a seamless, integrated experience to help your team work smarter and faster. To that end, we want to give you an overview of our updated privacy policy. It's more user-friendly and addresses new data regulations (including GDPR). Want to read the full policy? Check it out here. Looking for a quick summary of the updates? Read on: • Better navigation and user-friendly language. To make the policy easier to understand, we use clear, plain language and examples that illustrate our activities. We reformatted our privacy policy page with active links, so you can quickly find the information that matters most to you.    • How we integrate our products. We're always improving our products to give you a frictionless and customized experience. The updates to our policy describe the tools we’ve built to make our products smarter and allow you to move seamlessly from one Atlassian product to another.   • More control over your information. We make it easy for you to control the information you provide to us. Our policy explains how you can make choices about your information, and the measures we’ve put in place to keep your information secure.   • Using our products for work. Many users have access to our services through their organizations (e.g., their employers), who control their accounts or use of our services. The updated policy clarifies our relationship to these users and explains the tools available to administrators of these users.  The new privacy policy goes into effect on May 25, 2018. If you have any questions about these changes, take a look at the FAQs. For questions not addressed by the FAQs, please reach out to us using the contact information provided in the privacy policy.  We're proud to be part of your team!

JimiWikman

JimiWikman

What is the difference between the different project types in Jira?

One common question that often comes up is what the difference is between especially business projects and Software projects. In Jira Software this is not very clear and as a result I see almost all projects are created as Software projects. Lets go through the differences to see what a project type is and how it can be used in your project. In Jira there are three different project types that you can have: Business project - Jira Core. Software Project - Jira Software Jira Service Desk Project - Jira Service Desk The different project types comes with some specific features. This means that based on the project types you will see a different set of functionality in your project. These are referred to as Application Specific Features. In essence the choice between the different project types define a template that decides what the project you create will have in terms of functionality. If you accidentally choose the wrong type, then you can always change that later and the new choice will again create the functionalities related to the template.   Business Project If you choose Business Project, then you will get the default functions that are included in Jira Core. This project type is best suited for projects that work a lot with tasks. Software Project If you choose Software Project, then you will get the default functions that are included in Jira Core plus the functionalities to work with Agile Boards, Integration with development tools and release hubs for software version release. This is the recommended project type if you work in an Agile way and need the scrum board, or if you work with development so you need the release information or integrate with development tools. Jira Service Desk Project This add the service desk functionality such as SLA's and the Que view. It also add some specific Service Desk gadgets. This project type is useful for projects where SLA's are very important and in projects where you need a specific flow for support. Unlike the Business Project and the Software project this project type can feel very different as the view is arranged in a different way to better fit the need of a service desk staff.   A Summary of the Project Types   Project Types are NOT the same as Project Templates It is very important to understand that Project types are not the same as project templates. Project types define the underlying functionality of the project while templates change the layout and interaction with the project. We will cover the template types in a different blog post if you think that could be interesting.   If you want to read more about project types, feel free to read the Atlassian documentation here.  

JimiWikman

JimiWikman

Sign in to follow this  
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Who's Online   0 Members, 0 Anonymous, 0 Guests (See full list)

    There are no registered users currently online

here
×