Search the Community
Showing results for tags 'workflow'.
Found 9 results
-
Alternatives to Adobe Mastering Metadata Transitioning from InDesign to Publisher Illustrator Actions Shooting Raw Photos on iPhone The post CreativePro Magazine Issue 5: Alternatives to Adobe first appeared on CreativePro Network.
-
The Standard Defect Workflow is identical to the Standard Build Workflow, but with the addition of two statuses used in Defect Management. In Triage is used to indicate that the defect or incident is being looked at. The Rejected / Need Information is used as a soft rejection instead of closing the defect or incident as can not verify. This way, we reject the defect or incident back to the reporter and give them the opportunity to clarify their issue, or to close it themselves. This soft rejection is less likely to cause frustration and it helps educate the reporters on how to write defects and incidents properly. -
The Standard Build Workflow follows the Area of responsibility principle as well as the fetch and release principle. We place three AOR's in the workflow: Development, Test and Acceptance. This is because we use Confluence for the Requirement, Management and Design documentation and deployment is using the Release feature in Jira. Each AOR have 2 statuses as standard, with the "Ready for..." and "In ..." as standards for indicating waiting and active states. For the Development teams we have a third, optional status for Code Review as well since that is a shift in responsibility. We have New as the starting status to indicate that an issue has not yet been processed. We have a supporting status in the form of blocked/pending to indicate that issues are stuck or need external help to proceed. We end the workflow with a Closed status that indicate that the code has been written, tested, accepted and is ready to be put into production. All transitions except closed have a post functions added to it that set Resolution to None. This ensures that if anyone transition from closed to any other status, Resolution will always be none. -
The Standard Task Workflow is used for basic task management where we only want to check things off. It follows the standard New -> In Progress-> Closed flow with Blocked/pending as supportive status. All transitions except closed have a post functions added to it that set Resolution to None. This ensures that if anyone transition from closed to any other status, Resolution will always be none. On Close, we show the standard Close screen. -
BigPicture has nine distinctive modules plus the Overview “umbrella” module on top of them. Users can disable/enable individual modules on a per-initiative (e.g. project) basis. Let’s have a closer look at all 10 modules. Good news! Both BigPicture and BigPicture Enterprise boast the very same set of ten project portfolio management modules. Both apps let you turn on and off modules for each initiative (project) separately. For example, you are free to enable just Scope, Gantt, Resources, Risks, and Calendar modules for a classic project, and hide the rest. For an agile team – on the other hand – you could have Roadmap, Board, Teams, and Reports modules turned on, while the others might be off for simplicity. A hybrid project could have a selection or even all of the modules active. Take a look at figure 2. Can you notice how the Classic Project has a set of modules, unlike the one of the Less Requirement Area? This is how we got to the edge BigPicture Enterprise has: it is out-of-the-box compatible with SAFe, LeSS, hybrid management, etc. BigPicture Enterprise arrives with preset SAFe ARTs, LeSS Requirement Areas, Hybrid Projects, and others. For instance, the SAFe ART “template” has […] Artykuł BigPicture modules explained. A “sequence” of modules matches your workflow pochodzi z serwisu BigPicture.one. -
Regardless if you work in a continuous delivery flow like Kanban, a sequential delivery flow like waterfall or an iterative delivery flow like Scrum, you will benefit greatly from having portfolio management. Having a dedicated funnel ensures that you get a proper overlook of your incoming request. In this article we will discuss how that can be done by creating a process for it in Jira Software. Advanced Roadmaps is a very useful tool because it allows us to get the big picture. It also allows us to scale the hierarchies in Jira for issue types. This is important because the standard hierarchies are designed for teams, so they do not scale well. While you can work around this using the sideways approach where you have the higher hierarchies in a separate project and link between them, that is not really a hierarchy. This also works poorly when you wish to display things in Advanced Roadmap. The first thing we need to do for a proper hierarchy view in Advanced Roadmaps is to define the portfolio levels. We need to accommodate for multiple scenarios as requests, or demands, often come in different forms. The most common types are projects or even programs, or new features. We also want to make sure we can work with the different frameworks out there, so we add a collaboration level as well as defined in SAFe. To avoid a lot of confusion between different frameworks and other tools, we rename the Epic issue type in Jira Software to Feature. It will not be perfect, but it will have to do until we get the ability to rename it properly when Atlassian makes that change in the future. We do this by going to Issues -> Issue Types and edit the Epic issue type. We also add two new issue types for Initiative and Capability. Next we go to Plans -> Settings -> Advanced Roadmaps hierarchy configuration. There we add two new levels called Initiative and Capability and map them with our newly created issue types with the same names. Finally, we rename the Epic to Feature, and we should have our first hierarchy defined. We can go back and adjust this later if we want. The setup should now look like this: We can now add this to our projects by adding the issue types to our Issue Type Schemas. Depending on your setup you may want the new issue types for Initiative and Capability to exist in a separate Issue Type Schema, or you will add them to the standard schema. Either way we still need to give the new issue type a workflow that match their purpose. So we head over to Issues -> Workflows and create a new workflow. Again we want to consider what the purpose of these issue types is and who will actually work with them. Initiative, Capability and Feature are all used by management and requirement analysts to provide information on how to realize demands. That means that we do not have the same transfer of responsibility as for User Stories. Instead, we need to consider what we actually do in the portfolio and what we need to track in terms of activities. SAFe have a pretty good example of this for their Portfolio Kanban. Their first step is Funnel and for us that is pretty much everything that comes into our workflow, and we define this as new. Anything that comes in to the portfolio needs to be reviewed to see what we should focus on next. Since we will not review everything we add two steps for the review process: Ready for Review and In Review. This allows us to only pick things that we want to review by moving them from new to Ready for Review, and then we have an active status to indicate that we are working on this. We do the same for Analysis, which is the step where we involve Business Analysts and Requirement Analysts to define the need in more detail. For this we add Ready for Analysis for when the Review process lead to us spending time to break down the need in a requirement process. We also add the In Analysis to indicate that it has entered the Requirement process. Before we close this workflow we add the Implementation process as well. Ready for Implementation indicate that the requirement process has led to a decision to implement and In Implementation indicate that the need is being fulfilled. We do not fracture this further as we can easily drill down to individual tasks in Advanced Roadmaps, and it is not really useful to have for example test and release part of this workflow. That is because each issue type will have many issue types below it, and you can only transition on the last sub-task, making it misleading and feeling stagnant. Finally, we add a status for Blocked/Pending to allow us to track when things are preventing this activity from being fulfilled. This can be external or internal dependencies or financial reasons for example. As always we go for an open workflow to allow for free transitions. We add a close screen to the Close status to set a resolution and then add a post function to remove resolution on all other statuses. This workflow should now look like this: The final step is now to go to our workflow scheme and add this new workflow. We do this by going to Issues -> Workflow Schemes and click edit on the workflows scheme we have Initiative, Capability and Feature added to. We click add Workflow and add the new workflow we just created. Then we select that this workflow will be applied to Initiative, Capability and Feature before hitting save. This should now allow you to work inside Advanced Roadmaps using Initiatives, Capabilities and Features in a proper portfolio management process that allow for larger projects and programs as well as manage smaller feature or even user stories. I hope you found this useful and as always, if you have any questions just write a comment and I will do my best to help you.-
- 1
-
-
- atlassian
- jira software
- (and 7 more)
-
Regardless if you work in a continuous delivery flow like Kanban, a sequential delivery flow like waterfall or an iterative delivery flow like Scrum, you will benefit greatly from having portfolio management. Having a dedicated funnel ensures that you get a proper overlook of your incoming request. In this article we will discuss how that can be done by creating a process for it in Jira Software. Advanced Roadmaps is a very useful tool because it allows us to get the big picture. It also allows us to scale the hierarchies in Jira for issue types. This is important because the standard hierarchies are designed for teams, so they do not scale well. While you can work around this using the sideways approach where you have the higher hierarchies in a separate project and link between them, that is not really a hierarchy. This also works poorly when you wish to display things in Advanced Roadmap. The first thing we need to do for a proper hierarchy view in Advanced Roadmaps is to define the portfolio levels. We need to accommodate for multiple scenarios as requests, or demands, often come in different forms. The most common types are projects or even programs, or new features. We also want to make sure we can work with the different frameworks out there, so we add a collaboration level as well as defined in SAFe. To avoid a lot of confusion between different frameworks and other tools, we rename the Epic issue type in Jira Software to Feature. It will not be perfect, but it will have to do until we get the ability to rename it properly when Atlassian makes that change in the future. We do this by going to Issues -> Issue Types and edit the Epic issue type. We also add two new issue types for Initiative and Capability. Next we go to Plans -> Settings -> Advanced Roadmaps hierarchy configuration. There we add two new levels called Initiative and Capability and map them with our newly created issue types with the same names. Finally, we rename the Epic to Feature, and we should have our first hierarchy defined. We can go back and adjust this later if we want. The setup should now look like this: We can now add this to our projects by adding the issue types to our Issue Type Schemas. Depending on your setup you may want the new issue types for Initiative and Capability to exist in a separate Issue Type Schema, or you will add them to the standard schema. Either way we still need to give the new issue type a workflow that match their purpose. So we head over to Issues -> Workflows and create a new workflow. Again we want to consider what the purpose of these issue types is and who will actually work with them. Initiative, Capability and Feature are all used by management and requirement analysts to provide information on how to realize demands. That means that we do not have the same transfer of responsibility as for User Stories. Instead, we need to consider what we actually do in the portfolio and what we need to track in terms of activities. SAFe have a pretty good example of this for their Portfolio Kanban. Their first step is Funnel and for us that is pretty much everything that comes into our workflow, and we define this as new. Anything that comes in to the portfolio needs to be reviewed to see what we should focus on next. Since we will not review everything we add two steps for the review process: Ready for Review and In Review. This allows us to only pick things that we want to review by moving them from new to Ready for Review, and then we have an active status to indicate that we are working on this. We do the same for Analysis, which is the step where we involve Business Analysts and Requirement Analysts to define the need in more detail. For this we add Ready for Analysis for when the Review process lead to us spending time to break down the need in a requirement process. We also add the In Analysis to indicate that it has entered the Requirement process. Before we close this workflow we add the Implementation process as well. Ready for Implementation indicate that the requirement process has led to a decision to implement and In Implementation indicate that the need is being fulfilled. We do not fracture this further as we can easily drill down to individual tasks in Advanced Roadmaps, and it is not really useful to have for example test and release part of this workflow. That is because each issue type will have many issue types below it, and you can only transition on the last sub-task, making it misleading and feeling stagnant. Finally, we add a status for Blocked/Pending to allow us to track when things are preventing this activity from being fulfilled. This can be external or internal dependencies or financial reasons for example. As always we go for an open workflow to allow for free transitions. We add a close screen to the Close status to set a resolution and then add a post function to remove resolution on all other statuses. This workflow should now look like this: The final step is now to go to our workflow scheme and add this new workflow. We do this by going to Issues -> Workflow Schemes and click edit on the workflows scheme we have Initiative, Capability and Feature added to. We click add Workflow and add the new workflow we just created. Then we select that this workflow will be applied to Initiative, Capability and Feature before hitting save. This should now allow you to work inside Advanced Roadmaps using Initiatives, Capabilities and Features in a proper portfolio management process that allow for larger projects and programs as well as manage smaller feature or even user stories. I hope you found this useful and as always, if you have any questions just write a comment and I will do my best to help you. View full blog article
-
Version 1.0.0
12 downloads
We go over transitional and producing workflows, designing issue types and how to divide projects into a scalable solution that also can be used for SAFe. Stockholm AUG Leader Jimi Wikman show the setup he has built based on his experience as a project leader, release manager, designer, front end developer, requirement analyst and tester. He show his best tricks on what works in small and large scale organizations based on his experiences as a Jira expert. Prepare for a provocative and inspiring session where we dive into the 4 design principles for a sustainable, flexible and controlled Jira that works. For real. -
View File Designing Jira Workflows We go over transitional and producing workflows, designing issue types and how to divide projects into a scalable solution that also can be used for SAFe. Stockholm AUG Leader Jimi Wikman show the setup he has built based on his experience as a project leader, release manager, designer, front end developer, requirement analyst and tester. He show his best tricks on what works in small and large scale organizations based on his experiences as a Jira expert. Prepare for a provocative and inspiring session where we dive into the 4 design principles for a sustainable, flexible and controlled Jira that works. For real. Submitter ©Jimi Wikman Submitted 04/16/2020 Category Atlassian
