I am rebuilding this site (click to read more)
Jump to content

Articles

wdfw w ff wdf sfsfd sfdwdfsdfwerw r werw erwe rwe rwer werwer werw erwer we r we rwerewrwe rwe rwer wer werwer werwe

My Articles
Community Articles
Guest Blogging Information

My Articles

Show all categories

Dependency and progress for roadmaps in Jira Software Cloud

The roadmap feature in Jira Software Cloud's NextGen templates is getting a bit of an upgrade. In the new version we have two new features and soon we will get one of the features I am waiting for most.
In this new update for Jira Software Cloud we get two new features. Dependencies allow you to quickly link two epics together to indicate that they are dependent on each other. This is a great feature that allow you to visualize dependencies in your timeline.
The second feature is to indicate progress for child issues. This is shown below the epic name in the different status colors: grey, blue and green. This is not really as useful as if you could drill down on the items themselves in a hierarchy as you can in Portfolio for Jira. Still it is useful to quickly get a glance of the current status of things.

In the next version we will see the addition of roadmap hierarchies. This will allow us to open up the child issues so we can see them in the tree. Unfortunately the child issues does not seem to be shown in the same way and in the first iteration we only seem to get this for one level of the tree. Sub-tasks will not be seen in the hierarchy as it looks right now.

 
I feel that this is a step in the right direction, but I am concerned about the fact that the road map feature only exist for Cloud users and even more so that it is only available for NextGen projects. The features are much wanted and if we can get a good transition of Portfolio for Jira to a simpler and more useful tool, then I think that will be a great selling point.
For this to to be a replacement for Portfolio for Jira, which is positioned a bit between Jira Align and Roadmaps, then we need to be able to select what level we want to use and we need to be able to extend the parent child hierarchy with new levels. Using Epics in this way kind of annoy me since we are clearly working with features here rather than epics.
It will be interesting to see if Roadmaps will remain a cloud only feature and how it will fit next to Jira Align and Portfolio for Jira in the future. For now I am enjoying the new feature and look forward to the next upgrade.
Jimi Wikman
💫 Jimi Wikman

Apple Special Event. September 10, 2019.

Apple hosted it's special event on September 10th at the Steve Jobs theater at Apple Park in Cupertino, California. As expected it announced some new products, but as so often lately the presentation was dull and not very innovative.
The iPhone 11 and it's iPhone 11 pro version quickly became a meme with the 3 lenses that I have to say I think look ugly. We had the same hardware improvements as always, but nothing really worth upgrading for. Especially if you prefer a system camera anyway.
The new iPad is nice of course, but the big reason why it is interesting is because of the iPadOS coming at the end of September. Apple watch series 5 got it's always on functionality and we saw some new designs, but other than that it was not really anything I was excited about.
With Apple Arcade and AppleTv+ we see Apple moving towards the game and movie industry. This could be nice, but the question is how they will fight giants like Steam and Netflix for example. For me I don't care about Apple Arcade as I don't play much these days. AppleTv+ I will get for sure, if nothing else to test out and see how it stacks against other newcomers like Disney+.
Overall this special event was flat and boring. No new innovations and just the same old same of upgraded hardware. For me, even though I am a huge Apple fan, there is absolutely nothing in this event that i want to get my hands on. AppleTv+ would be the exception, but then again it is a service and not a device. this has been the case for quite a while now to be honest.
While I did get myself an iPad Pro and the new apple pencil, the only things I look forward to lately are the software upgrades. I feel that you can really tell how Apple is slowing down it's innovation pace and I hope that will change soon. Here is the keynote in case you missed it.
 
Jimi Wikman
💫 Jimi Wikman

Atlassian Launches free tiers for all cloud products

Atlassian has announced that a free tier for all of the company’s services that didn’t already offer one is coming. Atlassian now also offers discounted cloud pricing for academic institutions and nonprofit organizations. This is great for smaller companies that want to upgrade from the popular Trello platform, which is also owned by Atlassian.
Jira Software, Confluence, Jira Service Desk and Jira Core will get free tiers in the coming months. Exactly what the limits will be on these free tiers is yet to be seen, but it is safe to assume that the current 10 user tier that is the entry level will probably be free. In addition to this we will also see an extension of the trial version which is very short today. This allow companies to better evaluate before committing to a purchase.
"We’re announcing free plans of Jira Software, Confluence, Jira Service Desk, and Jira Core – available in the coming months. This adds to the existing free offerings already in place for Trello, Bitbucket, and Opsgenie to give teams of all sizes, even small ones, a set of fundamental capabilities for team collaboration." - Reaching new heights in the cloud
For me this is great news as it allow many smaller companies to get introduced to Jira. This allow Jira to organically become a foundation of the workflow as the companies grow. This should multiply the use of Jira quite a bit, especially with the new next-gen features that are very similar to Trello. I like this move quite a bit and I look forward to hearing more about this as the new tiers are published.
In addition to this they also talk about their Cloud Premium offer and the new discount offer for academic and non-profit organizations.
 
Jimi Wikman
💫 Jimi Wikman

Working with Invision Power Services is difficult, but rewarding

This site is built on Invision Power services and out of the box it is a very competent solution. As I dig deeper into the CMS however things quickly becomes a bit difficult. At the same time I continue to be amazed on just how powerful this system is.
When you dive into IPS then you quickly start to find areas where you need some guidance. This is when you try to figure out how to adjust a certain piece of data or how IPS template systems work. This is where things get a bit difficult because very little effort is made to support this kind of questions from IPS. They rely on the community to support each other, but unfortunately this works very poorly.
IPS used to have specific areas for each of their modules, but now that is gone and instead there is a generic area. For me who mostly need help with the CMS this is a pain because the CMS barely register as most still only use the forum. So finding the right information is difficult at best and if you ask, then you rarely get any help because so few actually know anything about the CMS. I think that 90% of all my questions are answered by OpenType, one of the few Pages experts on IPS. There are some documentation, but it is rudimentary and is more a base than actual documentation, so you really need someone to help you with the more specific areas.
Once you get through that obstacle then magic start to appear. I do not think i have used a software this powerful...ever. Just out of the box you can do pretty much anything you want. Then there are plugins and addons built by the community to further extent the capabilities. Once you start to understand how things are connected, then you almost get immobilized because there is just so much potential so it's hard to know where to start!
It is annoying ass hell sometimes, but at the same time it's just awesome when you figure out how things actually work and what you can do with it.
Jimi Wikman
💫 Jimi Wikman

Setup Jira and Confluence for success - Part 3: Defining Jira workflows

In the previous articles we have defined what tool to use for what and what issue types we need. New it's time to define the workflows for those issue types. Before we can do that however we should first define what workflows are and how we should use them in Jira.
Three types of workflows
In short we can narrow down workflows to three types: sequential, state machine and rules driven workflows.
Sequential workflow
This workflow is usually chart based from one step to the next, always moving forward without ever going back. Each step depends on the completion of the activities on the previous step. You can think of this workflow as a connect the dots system: you have to follow the numbers correctly, one after the other, to complete the big picture.
State Machine Workflow
This type of workflow can be considered like puzzle solving, in which you’re constantly putting important pieces in place to complete a project. State machine workflow are frequently used when there are creative elements in the process, or products and services that require extra review or input from clients and management.
Rules-driven Workflow
This workflow is executed based on a sequential workflow with rules that dictate the progress of the workflow. This can be compared to following a blueprint to make one complete structure. Rules driven workflows are very useful when working on a variety of projects with clear goals but varying levels of specifications.
We should also define what a workflow is NOT:
A workflows is NOT a process - A process is more then just a workflow as it includes data, forms, reports, actors and more. A workflow usually span over multiple processes as we hand over responsibility between different capabilities (requirement, development, test, acceptance).
  A workflow is NOT a list of unconnected tasks - Unconnected tasks are task management and not a workflow.
  A workflow is NOT a checklist - Checklists are binary. It's either done or not done. That is not a workflow.
  A workflow is NOT a state diagram - This is probably the biggest issue I see when people try to design workflows. The idea that you need to track every single state in a workflow comes from a misunderstanding of who we actually build workflows for and what they actually need.  
"A state machine (panel (a)) performs actions in response to explicit events. In contrast, the flowchart (panel (b)) does not need explicit events but rather transitions from node to node in its graph automatically upon completion of activities." - Wikipedia


 
Who do we build workflows for?
In order to understand why state diagrams are not the best choice to design workflows in Jira we should understand who we build workflows for and what purpose they serve.
The reason we use Jira is because we  want a good way to define and assign work. We also need a way to oversee, or manage, the work. This means that we want a way to track what work we are doing, what the current status is on that work and who is responsible for completing the work at the moment.
So for developers and testers we want en easy way to see what is ready to be worked on, what is being worked on and and what have we completed. For managers we need the same, but over the whole chain of responsibility. We also want to connect the work to the need so we can follow up when the need is being fulfilled.
So we have two basic need to fulfill:
What is ready for me to work on? Are we on track to fulfill the need or do I need to take action? In the previous article we mentioned transitional and producing items when defining what issue types we need. We can match these theories with these two need as well. #1 is producing as we just need to track the actual work in a fetch and release process. For #2 we use transitional as we want to track all areas of responsibility.
Based on this we can see that there is no need to see everything that happen in the work we do. We need to see who is doing what and if there are any impediments that could prevent us from completing the need in time. This is why we choose to work with flow charts and not state diagrams.
 
"Design for collaboration, not control"
 
If you feel that you must track every single step in the work, then I suggest you take a look at why you need that. Usually it is because you lack trust in your organization due to poor communication or that someone in the chain of management suffer from an unhealthy need for control. Either way you should fix that outside of Jira as we should design for collaboration, not control.
 
What statuses do we need?
So now that we know what types of workflows we have to work with and what the need is we need to fulfill, then it's time to break down what statuses we actually need. We start by defining the different areas of responsibility that we need to track in our workflows.
Development Test Acceptance First we start with adding a waiting status in each so we can fulfill the need of knowing what is ready for us to work on. This will also allow us to get statistics on waiting periods to see where we have resource issues. We name them the same to keep a proper naming convention: "Ready for <area of responsibility>".
Secondly we add a status for when someone is working on something. Again we can track this for statistics, but most importantly we can quickly see what is being worked on and by whom. We name this the same as well: "In <area of responsibility>.
We end the basics with setting a Closed status as the last status. This will allow us to set a resolution and indicate that the development work has been completed and is ready to be deployed. I often see people adding things like resolved or done, but in a workflow you should not have partial closure and there is actually no need for it.
We now have the basics for a fetch and release process and we have fulfilled the first need.
 

 
In order to fulfill the next need we need to add a few additional statuses, but first we should change the starting status. In Jira we have Open as the first status when a  new issue is created. This is a bad status as it is not clear what Open really mean and I have seen whole organizations failing due to this misunderstanding. So we will rename this status to New if we can do that for the whole organization. If not, then we create a new status and use that as our first status.
In order to track when something is blocked or waiting for something we add a status called Waiting/On Hold. Even though we can use the flag function to visualize this I have found that a dedicated status usually make this far more visible in the boards.
We will also add a Reopened status in the event that we need to open a closed status for some reason. This either happen because we close by mistake, but in the event that someone actually revoke a closed issue we want to track that. Adding this is a status allow us to define how we want to handle this situation later.
Finally we will add a status mostly used for defect management, but it can be used in any development workflow. That status is Rejected. While this can sound like a very harsh status it's purpose is to revert something back to the reporter for clarification rather than using the Close status and then Reopen.
With just these few statuses we can manage both need to see what is ready for me to work on (ready for <area of responsibility>), who is working on what (In <area of responsibility>)and if there are any issues that need attention (waiting/on hold). We can not take any issue type and look at what area of responsibility is involved in fulfilling that task and then map the statuses we have defined to that.
All generic workflows will have the same statuses. This makes it very easy to work with boards and no matter what capability you work with you always have only 3 statuses to keep track of: ready for me to work on, I am working on this, ready for someone else.
 
What about release management?!
Another common question is how I handle release management since there is no statuses for release. The answer to that is that we do not need that since Jira has that built into the core system in the form or versions. Every development should be closed with at least one version in the Fix Version field to indicate what code package the code is placed in. Every defect should also have an Affect Version that indicate what version of the code the defect was found in.
By doing this we can map what code is in what package, but Jira should never be master for this information. This information should come from Bitbucket, or similar code versioning tool. This is also the same for deploys, which we do not manage in Jira at all since that is a completely different process. This comes from Bamboo or similar tools.
The idea of managing deploys as a status in Jira quickly become silly as you would have a separate step that happen long after development, test and acceptance has been completed. This task is unconnected to the areas of responsibility. It is not a producing step, just a transportation step that is done not on story level, but on code package level. Like we established above this is not a part of a workflow since it is an unconnected task. We will however keep track of deployment in Confluence, but we will get to that in later articles.
 
Let's build the default workflow
Let us take all the theories above and make it real by designing the workflow in Jira and see if it hold up for real work.

 
Requirement & business processes happen outside of this workflow. The expectation is that the beginning of the workflow comes in the form of a clarified need as a story. Even in Agile way of working the story is clear enough to be worked on once put into the ”Ready for Development” status.
Once a story is clear enough to be worked on and we have acceptance from Development and Test, then we move the story to the status "Ready for Development". Producing items are created for development and we start working on the issue  by transition the store to In Development.
Once done we transition the story to Ready for development to complete the fetch and release process. This is repeated in the test and acceptance steps. In the event that we get a defect, then we create a defect sub-task and block the story from completion. We can use this for all development tasks as they all follow the same path.

Let's see how we set this up in Jira.
 
Building workflows in Jira
In order to build global workflows in Jira you need Admin access to Jira. Go to Jira Settings ->  Issues. Here you will find the two sections we need to configure to build a new workflow and to assign it to a project. Under Workflows you will see the current active and inactive workflows. In the top right corner you will see a button with the text "Add Workflow" Click that and you will get a popup to enter a name for the workflow and a description.

Once you have added a name and description you will come to the design view. Here you use the "Add Status" to add the statuses we want. We create them with global transitions to make the workflow as open and flexible as possible by checking the box "Allow all statuses to transition to this one".
I usually have transitions between rejected and new, as well as for Closed to Reopen, just to make it more clear that the rejection is used in a certain part of the workflow. This way you can't go to rejected or reopened from other statuses than the intended ones. In a proper workforce where the users get education on how to use Jira this is not really needed however so you can skip that if you do not feel it is necessary.

 
Add Workflows to a workflow schema
Now we can go to workflow schemes where you find all your active and inactive workflow schemes. in the top right corner you have a button with the text "Add workflow scheme". Click that and in the popup you add the name and description of your scheme. You will then be taken to the screen where you add workflows to the scheme and map it to specific issue types.
Click the add workflow button and select the workflow we created earlier. In the next screen you get to select which issue types you want to map to this workflow. Select the ones you like, which should be all of our development issue types and then click finish. Your scheme is now configured with a workflow that is mapped to the issue types you want. You can edit this scheme at any time should you add workflows and/or issue types.

 
Add Issue Type Scheme to your project
Go to your project and then click on project setting in the left menu. It should be at the bottom of the list of areas for your project, but if you can not see it then you may not have admin rights for your project and you need to get some help with this step. If you have access then in the project settings go to Workflows.
Here you see your current workflow schema and the workflows attached to it. To change click on "Switch Scheme" and select the new scheme that we created above. Click associate and if needed map statuses on the next screen and wait for all statuses to resolve. Once done you have your new workflow scheme mapped and you can start using your new workflow.

 
We now have workflows setup for our issue types, but we still have a few things to do before they are completely ready to be used. That is to define the screens and custom fields we will use in our setup. That will all be explained in Part 4: Defining Jira Screens & Custom fields that we will look at next.
 
Jimi Wikman
💫 Jimi Wikman