Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Certificate of Excellence - Praveen Soundarrajan 1.0.0

   (0 reviews)

1 Screenshot

About This File

When working at H&M as the Jira expert I issued Certificates of Excellence to the Gods of Jira team. This one was issued to Praveen Soundarrajan for his outstanding work as a Jira expert.

"For performing above and beyond
Awarded for working in a professional way with exceptional dedication
that has been above and beyond just being service minded. It is
also awarded for a positive attitude that is appreciated by
co-workers and clients alike. Finally it is awarded for being
passionate and being active in learning new things in Jira."


What's New in Version 1.0.0   See changelog

Released

No changelog available for this version.


User Feedback

You may only provide a review once you have downloaded the file.

There are no reviews to display.

  • Similar Content

    • By Jimi Wikman
      In the coming months we will see some changes to the navigation in Jira and Confluence for the cloud versions.  This after a round of feedback was done in July this year on the new experience. This change will roll out slowly and you can delay the change if you need time to prepare the users for the change.
      There has been some negative feedback regarding the current navigation in Jira and Confluence cloud as it is a bit difficult to use. This is why a new experience was designed and tested during the summer by 350+ users. The feedback on the new navigation was positive and so now it is going live to cloud users in a slow rollout.

      This is a rollback to the old navigation experience which is good as it will make the transition from Server and DC versions easier. I like the new apps and people sections in the navigation as well. That should make it easier to group things to keep navigation organized. The fact that Jira and Confluence now get a uniform navigation is also excellent.
      On the documentation page for the new Confluence navigation we find more details on the new navigation and it's design.

      App switcher - Switch to other Atlassian Cloud apps, like Jira, and go to recent Confluence spaces and Jira projects.
      Confluence logo and name - Click this to go to the Confluence Home page.
      Home - Begin your Confluence journey and reorient yourself when you’re moving on to a new piece of work by easily accessing the spaces, pages, and updates that are important to you.
      Recent - Access pages you’ve recently visited and worked on as well as pages saved as draft or starred.
      Spaces - Get to spaces you’ve recently visited and starred.
      People - Search for people on your site by visiting the people directory.
      Apps - Access content from apps like Analytics, Calendars for Confluence, or Questions for Confluence.
      Create - Click to create a new page, either blank or from a template.
      Search - Find pages, spaces, and other content.
      Notifications - Find out what's happening in Confluence and other Atlassian apps, like Jira.
      Help - Get online help, and find out what's new in your Atlassian Cloud apps.
      Your profile and settings - Go to or create your personal space, find out about the new Confluence experience, and adjust your Confluence settings.
       
      New Homepage
      In addition to the new navigation we will also get a new start page, or home page as it is called. This will appear in both Jira and Confluence cloud at the same time as we will see the new navigation.
      For Confluence it will give an overview over:
      Spaces - Get back to the spaces you care about, starred or recently visited Recent pages - Find pages you’ve drafted, recently published, visited, or starred All updates - View the updates across your site
       
      The Home page for Jira follow that principle, but is a bit slimmed down. I think there are more things that can go in this view and I hope we will see the same structure as for Confluence in the future. So instead of spaces we would have projects and then I would like to have a list of favorite boards somewhere.

       
    • By Jimi Wikman
      In the coming months we will see some changes to the navigation in Jira and Confluence for the cloud versions.  This after a round of feedback was done in July this year on the new experience. This change will roll out slowly and you can delay the change if you need time to prepare the users for the change.
      There has been some negative feedback regarding the current navigation in Jira and Confluence cloud as it is a bit difficult to use. This is why a new experience was designed and tested during the summer by 350+ users. The feedback on the new navigation was positive and so now it is going live to cloud users in a slow rollout.

      This is a rollback to the old navigation experience which is good as it will make the transition from Server and DC versions easier. I like the new apps and people sections in the navigation as well. That should make it easier to group things to keep navigation organized. The fact that Jira and Confluence now get a uniform navigation is also excellent.
      On the documentation page for the new Confluence navigation we find more details on the new navigation and it's design.

      App switcher - Switch to other Atlassian Cloud apps, like Jira, and go to recent Confluence spaces and Jira projects.
      Confluence logo and name - Click this to go to the Confluence Home page.
      Home - Begin your Confluence journey and reorient yourself when you’re moving on to a new piece of work by easily accessing the spaces, pages, and updates that are important to you.
      Recent - Access pages you’ve recently visited and worked on as well as pages saved as draft or starred.
      Spaces - Get to spaces you’ve recently visited and starred.
      People - Search for people on your site by visiting the people directory.
      Apps - Access content from apps like Analytics, Calendars for Confluence, or Questions for Confluence.
      Create - Click to create a new page, either blank or from a template.
      Search - Find pages, spaces, and other content.
      Notifications - Find out what's happening in Confluence and other Atlassian apps, like Jira.
      Help - Get online help, and find out what's new in your Atlassian Cloud apps.
      Your profile and settings - Go to or create your personal space, find out about the new Confluence experience, and adjust your Confluence settings.
       
      New Homepage
      In addition to the new navigation we will also get a new start page, or home page as it is called. This will appear in both Jira and Confluence cloud at the same time as we will see the new navigation.
      For Confluence it will give an overview over:
      Spaces - Get back to the spaces you care about, starred or recently visited Recent pages - Find pages you’ve drafted, recently published, visited, or starred All updates - View the updates across your site
       
      The Home page for Jira follow that principle, but is a bit slimmed down. I think there are more things that can go in this view and I hope we will see the same structure as for Confluence in the future. So instead of spaces we would have projects and then I would like to have a list of favorite boards somewhere.

       

      View full blog article
    • By Jimi Wikman
      The Roadmap feature in Jira Cloud's NextGen projects is getting three new features. While all good additions, the question still remain who these new features are for and to what extent these new features will make people move over to NextGen projects.
      NextGen for Jira Cloud is in a strange place as it is not really defined what is can and should be used for. The Roadmap feature is in a similar place as it fall somewhere between Portfolio for Jira and the Roadmap planner macro in Confluence. These 3 new features are an improvement and a good indication on where Atlassian are going. The question is just how fast these new features are coming out and if it appeal to the target audience.
      Drill down into the details

      The first feature is the ability to open up the Epic and see the underlying tasks. This is a much needed feature that was heavily requested and also one I spoke with Atlassian about earlier this fall. This is a good feature and a good step to improve the roadmap, but is still in need of further refinement.
      We still only have Epics as the starting point, which will limit the use of Roadmaps. Opening up the subtasks will only show their status at the moment, which is useful, but not what many want. Many still want a Gant view where the sum of the subtasks should make up the time in the Epic. This is not possible at the moment and I find it interesting that Atlassian has chosen to follow an Agile first approach to the Roadmaps, which means it will not be very useful for the majority of the companies using Atlassian's products today.
       
      Add new tasks directly in the Roadmap

      Another great feature that was much requested is the ability to create new sub tasks directly in the Roadmap.  This way we can build up a full stack of tasks for a project in one view, which is excellent for portfolio and project planning purposes. The fact that we do not get full Gantt view for the sub tasks makes this a little less useful for time and resource planning however.
       
      Filter your Epics and Tasks

      The ability to use different filters is a must for any Portfolio, but even roadmaps benefit from filtering options. In this release we get the filters for issue status and assignee, which is a good start. I would like to see some more filters like dependencies and of course issues that are behind the time schedule. The question is just who this Roadmap feature is for though as then we are moving more into project management and Portfolio management and Atlassian has previously stated that the Roadmap is for teams.
       
      It's a good start, but...
      I am still not sure where NextGen projects are heading, which means it's hard to say if the features are great or poor. We know that Roadmaps will be ported over to the Classic project types as well, but that will make things even more confusing. This is unfortunately a common issue with Atlassian as they are getting more and more fractured with no clear indication on structure or strategy.
      Roadmaps for me is something that should stay as a team tool for small teams to give an overview of the current work. To cater to that need Roadmaps could benefit from a few changes.
      The first would be to change the basic structure and allow the view to be in any level. That means that I should be able to use Stories rather than Epics as Epics are just containers and not work tasks. The majority of issues are not connected to Epics in most teams, especially if you work in a Kanban setting for continuous improvements for example.
      The second would be to go full gantt, or rather to give the option to go full gantt. Not every team need or will use estimation in issues, but most do. Without a full gantt the view of issues will not be as useful as a progress overview tool. It's like saying that I have a container of a certain size and in that container I have put five items. On the question if the items will fit my only answerr will be "I don't know", which is in many organizations not an acceptable answer.
      The third would be to add dependencies on issues and not just on Epics and extend the data to also show data from other projects. In most organizations dependencies are not within the team itself, but to surrounding teams. Even if the view is for the team it makes sense that I should be able to see what other teams could be affected.
      The fourth would be to ensure that Roadmaps becomes a granular part of a larger view. Right now it is an isolated feature, which means that we will have different data for different levels of the organization. This will lead to miscommunication within the organization as teams will say Epics, which will mean something very different to Program managers and Portfolio managers and so on. As more and more organization add SAFe to their processes it is important that the team view is part of the greater whole.
      I am sure we will so many great additions to Roadmaps in 2020 and hopefully many of the questions we have regarding Roadmaps and NextGen projects will get answers then. Until then these three new features are welcome additions that I am sure will help many teams improve their work processes.
    • By Jimi Wikman
      The Roadmap feature in Jira Cloud's NextGen projects is getting three new features. While all good additions, the question still remain who these new features are for and to what extent these new features will make people move over to NextGen projects.
      NextGen for Jira Cloud is in a strange place as it is not really defined what is can and should be used for. The Roadmap feature is in a similar place as it fall somewhere between Portfolio for Jira and the Roadmap planner macro in Confluence. These 3 new features are an improvement and a good indication on where Atlassian are going. The question is just how fast these new features are coming out and if it appeal to the target audience.
      Drill down into the details

      The first feature is the ability to open up the Epic and see the underlying tasks. This is a much needed feature that was heavily requested and also one I spoke with Atlassian about earlier this fall. This is a good feature and a good step to improve the roadmap, but is still in need of further refinement.
      We still only have Epics as the starting point, which will limit the use of Roadmaps. Opening up the subtasks will only show their status at the moment, which is useful, but not what many want. Many still want a Gant view where the sum of the subtasks should make up the time in the Epic. This is not possible at the moment and I find it interesting that Atlassian has chosen to follow an Agile first approach to the Roadmaps, which means it will not be very useful for the majority of the companies using Atlassian's products today.
       
      Add new tasks directly in the Roadmap

      Another great feature that was much requested is the ability to create new sub tasks directly in the Roadmap.  This way we can build up a full stack of tasks for a project in one view, which is excellent for portfolio and project planning purposes. The fact that we do not get full Gantt view for the sub tasks makes this a little less useful for time and resource planning however.
       
      Filter your Epics and Tasks

      The ability to use different filters is a must for any Portfolio, but even roadmaps benefit from filtering options. In this release we get the filters for issue status and assignee, which is a good start. I would like to see some more filters like dependencies and of course issues that are behind the time schedule. The question is just who this Roadmap feature is for though as then we are moving more into project management and Portfolio management and Atlassian has previously stated that the Roadmap is for teams.
       
      It's a good start, but...
      I am still not sure where NextGen projects are heading, which means it's hard to say if the features are great or poor. We know that Roadmaps will be ported over to the Classic project types as well, but that will make things even more confusing. This is unfortunately a common issue with Atlassian as they are getting more and more fractured with no clear indication on structure or strategy.
      Roadmaps for me is something that should stay as a team tool for small teams to give an overview of the current work. To cater to that need Roadmaps could benefit from a few changes.
      The first would be to change the basic structure and allow the view to be in any level. That means that I should be able to use Stories rather than Epics as Epics are just containers and not work tasks. The majority of issues are not connected to Epics in most teams, especially if you work in a Kanban setting for continuous improvements for example.
      The second would be to go full gantt, or rather to give the option to go full gantt. Not every team need or will use estimation in issues, but most do. Without a full gantt the view of issues will not be as useful as a progress overview tool. It's like saying that I have a container of a certain size and in that container I have put five items. On the question if the items will fit my only answerr will be "I don't know", which is in many organizations not an acceptable answer.
      The third would be to add dependencies on issues and not just on Epics and extend the data to also show data from other projects. In most organizations dependencies are not within the team itself, but to surrounding teams. Even if the view is for the team it makes sense that I should be able to see what other teams could be affected.
      The fourth would be to ensure that Roadmaps becomes a granular part of a larger view. Right now it is an isolated feature, which means that we will have different data for different levels of the organization. This will lead to miscommunication within the organization as teams will say Epics, which will mean something very different to Program managers and Portfolio managers and so on. As more and more organization add SAFe to their processes it is important that the team view is part of the greater whole.
      I am sure we will so many great additions to Roadmaps in 2020 and hopefully many of the questions we have regarding Roadmaps and NextGen projects will get answers then. Until then these three new features are welcome additions that I am sure will help many teams improve their work processes.

      View full blog article
    • By Jimi Wikman
      In the last article we talked about defining workflows, so now it's time to talk about defining custom fields and screens. The custom fields is where most companies make many mistakes by trying to build new ways for Jira to work and screens almost no one seem to use. Let us change that, but first let us go over what these things are. We start with custom fields.
      Custom fields explained
      Custom fields are extensions of the data built in to Jira by default. This allow you to make adjustments to your Jira instance in the event that you need it. Custom fields comes in many pre-defined formats such as date fields, droplists, labels and even cascading select lists. In short you can model the data you work with pretty much any way you want. That is usually also the big problem with custom fields...
      Custom fields are defined just like most things in Jira using attaching the custom fields to a scheme. For custom fields this is called Field Configuration Schemes. These schemes connect a custom field configuration with the custom fields. This field configuration is what defines how each custom field should be used in a specific context. This allow you to have different behavior and configuration for the same fields.
      Custom fields - new data objects that extend the database model. Field configuration - Definition of configuration and behavior for custom fields. Field configuration schemes - map fields with field configurations. This is attached to a project to define that projects field configuration.  
      Impact on performance
      Custom fields have an impact on performance. Period. Anyone who think otherwise do not understand how custom fields work or what impact they have on the system.  Jira uses an indexing system that cache data in order to quickly find the relevant data you search for. For this Jira uses Apache Lucene, an open source high-performance, full-featured text search engine library written entirely in Java.
      Whenever you use a board, filter, dashboard or search in Jira you will use Lucene. Every custom field you add will grow the data exponentially in the index as it will be added to every single issue in Jira, even if that issue does not have any data in the field.  Just by adding custom fields you will see an impact on performance and if you are careless about the size of your projects or do not manage your releases properly, then you can render the Jira instance almost unusable dye to loading time.
      Use custom fields with care!
       
      Mandatory fields impact
      Mandatory fields can be set in the field configuration. This will make a certain field mandatory that you have to fill in. This may sound like a great way to force the users to fill in the data you want them to, but in reality it is causing serious issues, especially when working with any form of integration.
      When you have integrations that send data to Jira, then do not use mandatory fields, or make sure that it is mandatory for all projects. Having multiple versions of what data is mandatory is a sure way to make integrations fail. This is because we set up a condition that say that unless this data is part of the data you want to submit, it will fail.
      The most common reason for using mandatory fields is because the teams do not understand why they should fill in the data. This is because of poor education on how the workflow should be done or because the way it is designed makes no sense to the people actually doing the work. This should be solved on a method and process level and not in the tool.
       
      Building new systems in Jira with Custom fields
      The biggest failure I see in Jira is when custom fields are used to extend the capability of Jira to something it is not built for. The most common thing I see is that a story is used as a business need and then kept all the way though deployment. I understand the thought behind it, but the execution will require dozens if not hundreds of new fields and it will just become a mass of data that is almost impossible to work with.
      Jira is first and foremost a development tool. It starts with a need that has been transformed into a work order for the development team. In many cases you also have test included in Jira. Often as a plugin or just in the workflow itself. That is all Jira should do as there are other tools that should handle business need, requirements as well as build and deployment.
      In large organizations this behavior is very dangerous. I often see people getting burned out or just give up an aspiration of coherent and logical way of working as the systems evolve to grotesque monsters no one really understand or want.
      Do not build new ways of working, stick to the standards that exists and you will be much happier. If you are going to extend the capabilities of Jira, then always use a Jira designer that can design the system globally for all users. NEVER allow teams and groups within the organization to design on their own, unless they are an isolated group that never need to work with outer teams or systems. That lead to a fragmented way of working that will cost millions to repair in the future.
       
      One field to "always" use
      Despite all the issues that comes with custom fields there is one field I always think makes sense. There are others of course because in all organizations there are a few fields that makes perfect sense and that really improve the way of working. One such field is "Team", but only if you are not using a plugin like Portfolio for Jira as that already have teams built in.
      The reason why team is useful in almost any scenario is because it allow you to work across Jira Projects in a standardized setup. This way we can avoid Jira projects with hundreds of people and instead work with boards. Using this field you can assign issues to teams rather than people allow for cross project assignments. We will discuss this more in future articles.
       
       
      Screens and why they matter
      Where custom fields are abused to the point of absurdity in many organizations, screens are barely used at all in my experience. This is strange as screens are very useful for making sure you are working with the right data at the right time. This will make things much easier when creating new issues or allow you to have certain data filled in during transitions in the workflow.
      Screens are divided into 3 views:
      View screen - The view used when you look at an issue i Jira. Edit view - The view showed when you edit the issue. Create View - the view when you create an issue. This allow us to focus the information in creation view for example to make sure that we only see the fields that we actually need, and then have all information in view and edit.
      When defining screens we have three parts to do so:
      Screens - Where we define what data should be available in the screen. Screen Schemes - Where we define what screens should be used for the View/Edit/Create views Issue Type Screen Schemes - Where we define what screen schemes should be used for the different issue types. One common use of defining screens is to define the create view for defects. This allow for a more focused defect report process where only the fields we really need is shown when creating the defect. Once created it will allow for all the same fields as a story since it is actually a story that describes a need that has yet to be addressed.
       
      Defining fields in a screen
      So, first we start by defining the screens.  First we want to create a new screen for defects so we can define the fields we want when creating new defects. We go to Jira Settings ->Issues -> Screens where we find all our current screens. Then on the top right we can click the button to create a new screen. Add a name and a description and then click add.

       
      This will take us to the screen configuration page where we can define the data we want. Since this is a defect we want to capture the problem, where the problem occurred and also who should get the defect to look at. We define the fields like this:
      Issue Type* - Needed to we can set this as a defect. Reporter* - So we know who reported the defect for follow up. Summary* - The headline that summarize what the problem is. Environment* - Where was the defect found (test, pre-prod, dev and so on). This is needed for defects, but if this had been for production incidents we would not need this field as it is always in production. Affects version* - what code base or release is this related to so we know in what code we should look for it. Description* - This is where the defect is described. It should be steps to reproduce and expected results. Attachments - Pictures or videos that help describe the defect. NEVER upload office files here as you need to download them, which is a horrible way to work. Assignee - Sometimes used to assign a defect to a QA lead for example or a Project manager for attention. Responsible team - When the responsible team in known it can be added to the defect as well. Priority / Severity - How bad the defect is and not how soon it should be fixed. Components - what area of the system the defect affects. Labels - for labeling. Linked issues - If there are other issues that are relevant to the defect. Epic Link - If you use epics to group things. * These fields are mandatory. The rest can vary depending on your work process.
      It is important that these fields are also available in the default screen. If they are not present there they will not show as we do not have custom screens for the view or edit screens in this example. If you forget to add them, then do not worry. The data will still be there, but it will not show until you have added the fields to the screen.
       
      Defining views for Defects
      With this done our next step is to define the three views for defects so we later can attach it to the right issue type. We do this by going to Jira Settings ->Issues -> Screen Schemes and click on the button saying Add Screen Scheme. Add a name and a description, then set the default screen. This should not be the new screen we created as that one will only be used for the create action. You can change this later if you want.

       
      With that in place we come to the configuration page where we assign screens to the three actions we have (Create, View, Edit).  By default you have one screen defined for all actions here, which is the one selected when creating the screen scheme. Now we will add our new screen to the create action and we do that by clicking the top right button that says "Associate an issue operation with a screen".  Now you can select one of the three actions and a screen. We select the create action and connect that to our new defect screen and click add.

       
      Defining screen schemes to defects
      Now that we have the screen configured we need to add it to the correct issue and to do that we first need to create a issue Type Screen Scheme. We do this by going to Jira Settings ->Issues -> Issue Type Screen Schemes. Again we click the add button in the top right and add a name and description. This time we also can select a default screen scheme so we add the default screen sheme that will be used for all actions rather than the custom field we created for creating new defects. This can be changed later if you want.
      Once we have this created we get into the configuration screen. Here we will have a default screen scheme set for all issue types. Now we will need to add the new screen scheme we created for defects here. We do that by clicking the button in the top right that says "Associate an issue type with a screen scheme".  Select the issue type Defect and then the screen scheme we created earlier and click add.

      ...and we are done.
      From now on we will always see the fields we have defined in the Defect screen when we create new defects. We can edit the fields as we see fit and it will not affect any other screens. Since we did not create custom screens for edit or view it means that we will see the same fields as for all other issues once the defect has been created.
       
      Focus information when needed
      As you can see it is not very complicated to add new screens, but they can add quite a bit of focus to your workflow. For this example we created a focused screen for reporting defects, but you will most likely want additional screens. One such screen that I almost always add is the Resolve screen that shows up when you resolve an issue. This is done by adding a trigger in the workflow that add a screen on an action as a popup.
      We will cover that setup in another post.
      I hope this was useful for you and in our next article we will discuss Jira security & access. In case you have missed any of the previous articles you can find them all here.
       

      View full blog article
×
×
  • Create New...