Our company has recently introduced Azure DevOps to streamline project management process. Currently, 140 projects are created under our organization in Azure DevOps. As and when requirement comes from client for any specific project, we create tasks/bugs for different developers under that project. Currently we use only two Work Item type - Bug and Task.
Now the issue is Management of the company wants to see Project-wise number of "New/Open", "Active" and "Closed" Tasks and Bugs in a SINGLE chart. That means, that single chart must fit consolidated data of 140 projects. If a person views that single chart they must get idea, for example that - Project 1 has 2 new/open work items, 2 active work items and 2 closed Work items , Project 2 has 1 new/open work items, 10 active work items and 3 closed Work items and so on.. This is done so that management in a glance can understand which project is lagging behind for customer delivery. So that they can work accordingly build more manpower for those Projects.
I have tried to create various such charts and widgets with different queries in Azure DevOps. I used widget burn up and burn out charts but it gives data for tasks of single Project only. Also when we add multiple projects to it, it shows summation of completed/remaining tasks for those Projects & NOT Project name-wise completed/remaining tasks bifurcation.
I also tried "Charts for work item" widget but it also fetches count as per- Assignee, State and Work Item type and not project name wise count is fetched.
I don't want to navigate through 140 projects pages to see it's open, active and closed tasks. So please help me out in suggesting the ideas on How can I build a single chart from where we can get all this data? I will be forever grateful for your answers.
Thank you!
You could create a query across projects, select Team Project column in Column option, ad save the query as shared query. Check the screenshots below:
Then add a chart widget to a dashboard, select Pivot table, and set Team Projects, State as Rows and Columns. Check the screenshot below:
You could expand the view to see more details:
https://learn.microsoft.com/en-us/azure/devops/report/dashboards/charts?view=azure-devops#add-a-chart-widget-to-a-dashboard
I'd be slightly careful based on what you've put down because I don't think your management team quite understand what they need, and DevOps can only do so much. I'd be challenging them around the setup of your DevOps process personally because I don't think it's advisable to not have user stories as part of your setup. Although it simplifies some aspects of DevOps, our experience has been that people have been able to group things together better with user stories as well as tasks.
Appreciate it's a good idea to be able to see what's going on across all projects, but I think there are probably further criteria to think about. E.g. do you want to see estimates instead of/as well as the count of the items since that will have a better reflection of the effort required. In terms of completed items and in fact, probably all that you're displaying, again it's more on your project process, but are management genuinely interested in everything? For example, do they need to know that something was closed 6 months ago, or are they just interested in the last month?
I suppose what I'm getting at is you probably need a bit more information from management about what they want to use the report for so you can give them what they need rather than they want. There's a temptation to say you want everything because you don't understand the capabilities of the solution or what you're going to use it for, and my recommendation would be to challenge them on this so you can better present things (giving them what they need rather than what they want).
In terms of what you're looking to do, I'll openly admit I'm not clued up on everything DevOps related but I doubt you'll be able to report at a project level within DevOps. I think what you'd need to do is set up your query, which would look across all projects in your organisation, and then export the results to Excel. From there I'd create a pivot table (or perhaps more than 1) with the data that you need. Have Project names down the left side (row headers), and bring in whatever else you need as columns. I think that's probably a good quick win to get something in front of your management team, and then you could challenge from there - almost picking holes in it so that they realise that the business decisions that they'd make from this may not be fully informed, and suggesting some changes. From experience, it's probably better to consider it almost as a prototype and not get bogged down with a solution at this stage because you may be asked for changes when they can visualise what they've originally asked for. Once management is happy you could look at other solutions to provide the report, but Excel is typically a good starting point I've found in the past when working on something new like this.
Related
I'm curious with usage of DevOps boards/sprints/kanban, what is the industry standard for handling usage by multiple stakeholders?
More specifically, DevOps comes with standard states like "Active/Resolved/etc", but what if we want to capture more, such as "Deployed to env X", or even testing statuses. I know we can add additional statuses, but is that the right thing to do?
The challenge we have, is if the Kanban is used, then all those statuses must be represented on the Kanban, because movement on that board actually sets the status, so if we remove a status column from the Kanban, any WI with that status would effectively be hidden.
So effectively, I've added a bunch of statuses to cater for environments, testing, different reasons for on-hold, etc, but its being argued that this makes the Kanban too complex to get an easy snapshot of whats happening.
It's been suggested that we remove all these statuses, and instead use Tags and Swimlanes, which seems much less robust to me, it accomplishes the same thing, but without a single source of truth like the status provides.
Just curious if anyone with more experience with DevOps can shed light on how they've tackled this.
It looks that you want to get feature which is not implemented - Allow multiple states in the KanBan Board Columns
Actually the TFS allows only one state for every column in the KanBan Board which makes the whole developing process messy. We had to create several columns for all the states that our dev team has. It would be great if TFS could allow to assign multiple states to the columns, and doing and done columns to reduce the number of columns in the whole process.
There is no way to overcome this and what you need.
You can create custom field with pick list and then configure Kanban to display this field on the board:
This maybe helps you a bit.
(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.
Background:
JIRA offers a single set of statuses for all types of issues in a project.
Problem:
The problem is that the status set for a task is ToDo, InProgress, and Done. While for a UserStory in the same project it might be Designing, Developping, Testing, Releasing, and Done. It can even be different for a bug or an Epic.
Question:
How do you keep track of the workflow of your product and at the same time manage the status of your tasks using the single set of JIRA status.
PS: I know they can be customized for each project, but it doesn't help because you can't customize them for each issue type separately.
I think one of the reasons that JIRA offers the To Do, In Progress, and Done is that these can apply to anything. You either haven't done it, you're doing something, or you finished. That set can apply to any type of item.
That being said, I feel your pain in wanting to have a better view into the true state of an issue. What we have found we use for our OnDemand agile boards is to set up something like the following:
To Do
In Progress
Ready for Review
In Review
Done
For most types of issues, this can work. It adds that bit of extra layer to be able to identify what is ready for testing.
One of the things that is tricky is dependent tasks. For example, I noticed you mentioned "Designing" as a stage, and I'm not sure this makes sense in an agile sense. If the design is emerging from the development, it may be better to allow the design/development to flow within the development team. However, we all know that sometimes you need to get some details ironed out before you can proceed, or there may be some people that need to become involved before a dev can proceed. We made the mistake of trying to turn this into a stage, but what we found was that this was really either a sub-task for part of the team, or an impediment (blocker). By flagging stories, you can identify that a story requires something to be done before the development team can proceed.
If you are using Kanban, and not a Scrum board, the sub-task approach will not be for you. In those cases, you'll just need to make sure you have stages that make sense for all the issues you create. Stages will have to be fairly 'generic'. This sounds bad.
But it is not!
I believe teams generally use the stages for a few reasons:
Checking on status of an iteration
Inform other team members that they can pick up an item
Try to get a visual estimate on how close to Done an issue is.
More stages doesn't necessarily give a better status on an iteration as you really just need to see how many points you've closed and how many are in progress. So, at least for that goal, a more generic set of stages should work.
As for informing team members, too often I've seen teams retreat to the digital board to replace communication with each other. The fewer stages you have, the more you can force your team to talk to each other and work together to get a story to done. Things will work better this way, I guarantee it! Having a bit of a break-down helps, especially if you are working on a lot of items at once or have distributed teams working in different time zones, but keeping it simple is usually better.
Tracking the "how close to Done" is the hardest to do with generic stages. However, the multiple stages can be misleading. An item that is almost all the way across might have a severe bug in it that hasn't been found yet, so no matter how many stages you have your view on this item isn't any more accurate than a single "In Progress" stage. It isn't Done until it's Done :)
This was a long way for me to recommend keeping your workflow simple and letting your team use communication to keep on top of things. Maybe I should have just started with that!
The statuses that are available to each project is determined by the Workflow to which it is assigned. Not only does a workflow define the statuses, but it also defines what statuses you can progress to from a particular status. You can either create your own Workflows or you can download predefined workflows that suite your need.
In order to have separate workflows for different issue types, we need to define a Workflow Scheme:
1- Go to Jira Administration -> Workflow Schemes
2- Edit the Wokflow Scheme that is assigned to your project
3- Click the "Add Workflow" to add a new workflow for the issue types for which you need a different workflow and assign those issue types.
Our company is moving over to Jira for all project management and issue resolution
We have a few major uses that i am trying to build templates for. One being a typical issue found and fixed and can easily be handled with a single issue with basically the included jira workflow.
A more complex one is following a Waterfall workflow where Requirements are gathered including an estimate. Then Development kicks off, and in parallel test scripts are made. After Development is done the project is tested and handed off to the client. And finally once all is tested we release the change and re-test. In total I have 30 different steps built across 5 Sub-Tasks (However this is all just mapped out in Visio and not actually in jira yet).
The splitting across Sub-Tasks I hope can accomplish 2 things. First is that we want to track open-close times and efforts (hours works and days needed). And we should have the workflow split to multiple people so the Developer can work while a Tester can build their testing plan. That is able to save a few days, however is not a deal breaker.
So a few questions that I hope can help make this possible, although I am quite new to the various add-ons for Jira, I have no idea if we will get everything we want.
1, Is there an add-on that builds templates of Sub-Tasks, since each Sub-Task needs its own workflow. Currently the rules for Jira is to assign a workflow based on Project+Issue Type. So I believe I can have the proper piece of the workflow assigned to each Sub-Task by creating many Issue Types, like "Custom-Dev-Analsys" for the Sub-Task called Analysis
2, Is it possible to have only 1 or a few of all Sub-Tasks being the "current" one? When the issue starts the first Sub-Task should be the only one worked on, with only 1 of the steps being assigned to someone. After sign-off there should be 2 Sub-Tasks, the Development one and building Test Scripts. But all 5 sub-tasks should not be started since the very beginning, but it seems thats what Jira will do. I have looked at the add-on "Structure" and while that has unlimited hierarchy, I do not think it will let the sub-tasks open up in order. There might be a simple way to make the workflow open the next task (I am very new to workflows and trying to learn as much as possible before messing with our site)
3, If anyone can think of some way to do what I need differently, I am all ears.
Thanks!
I don't know any plugin that does all what asked for, but I had to deal with similar issues, and managed to sort most of them out with the Jira Scripting Suite, but it did require some development (using python).
It's easy to add to your workflow transitions that will create or close a new issue or a new subtask. I use it to create subtasks just by filling some required fields in one of the issue's screens. After the sub-tasks are created, only the automated scripts can close the issue, and that can be done by closing all of the subtasks.
If this kind of solution suits you I will be happy to help with any further inquires.
JIRA doesn't support nested workflows but one useful thing to remember is that if you change the issue type of a JIRA issue, it can have a different workflow. So an issue could start as TEST-123 which is a Requirement. Then after it reaches the end of its workflow it could be Moved to be a Task issue type.
Subtasks should stay as before.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are currently utilising an agile environment in work. One of my tasks involve setting up a release timetable. A part of this is providing a time frame of how long a project would take to go from a development environment, to staging and then live.
I have conflicting thoughts regarding whether such a timetable needs to be done.
For a start, we are quickly moving into a Continuous Integration / Constant Delivery environment where an application is tested amongst all environments when a change is made to the code base. Therefore, there is no time frame, but things should be "just" deployable. (Well, we always need a little bit of contingency as the best laid plans can always go awry)
Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.
Regards,
Steve
Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.
First of all the Scrum Framework guidelines never guides you to not have a Release Plan or Time table ever. What is leading you to have conflicting thoughts? I would like to know the source which is leading you to this conflict.
Best way to create a Release Plan is like this (this may take a week or so depending on the size of your project):
Get the Stakeholders in a room and get a EPIC user story written on the board using their guidance. The EPIC user story should include the end product vision. (ignore if already done)
List out the type of users.(ignore if already done)
Break the Epic user story into smaller and smaller chunks of user stories till they are small enough to be doable in sprints.(ignore if already done)
Ask the Product Owner(s) of the Scrum Team(s) to prioritize the stories in the uncommitted backlog list(s) Also do some form of effort estimation fairly quickly and do not waste a lot of time estimating.
Get the target end date or Go Live date of the project from Stakeholders.
Divide the time frame from now until the end date into Releases. Ask the stakeholders which features need to be delivered by when and include the appropriate user stories in them, and call them Releases. You can also give those Releases themes if needed.
The Release Plan now is conceptualized.
After this draw it on a white board or put it in a visible and transparent location where everyone can see it - add user story cards to the appropriate release.
Now your initial release plan should be ready
Ideas for implementation:
Form a Scrum Team specifically for Operations Activities. They could follow Scrum or Kanban would be better.
As and when Development teams get "shippable products" put in the shelf, the Operations Kanaban Team can do the deployment and release branching etc tasks as per the Release Plan.
So this way the development Teams don't really focus on the Release plan or work, just the Operations Team does that. The Development Team just focussed on the Sprint Work, it would be the Product Owners headache to make sure the right user stories are in the right Release and in the right order. The direction would be given by the Stakeholders.
To be honest you really don't have to do anything yourself, it's all in the stakeholders and POs hand, I don't know where is is the fuss??
I hope you get the picture.
I usually maintain a release plan for the management that is mainly based on a combination of the estimated & prioritized user stories (I group them to match a main new feature of the product) and velocity.
With a well maintained product backlog it's pretty easy to do your release plan. I usually plan three to four releases a year.
What I like with Scrum is that I can potentially release after each iterations.
If you want to master your release management, you will need more information that few answers of practionners. I highly suggest you this book.
If you currently utilising and agile environment you should check Agile estimating and Planning book for some suggestions. This book also contains small chapter about Release planning.
Some release planning should be always done. Release is a target wich usually covers 3-12 months of development = set of iterations. It something which describes target criteria for project to success. It is usually described as combination of expected features and some date. Features in this case are usually not directly user stories but epics or whole themes because you don't know all user stories several months ahead. Personally, I think release is something that says when the project based on vision can be delivered. It takes high level expectations and constraints from the vision and converts them to some estimation. You can also divide project to several releases.
But remember that three forces works in agile as well. There is direct relation among Feature set, Release date and Resources (+ sometimes also mentioned fourth force: Quality). Pushing one of these forces always move others. It is usually modelled as equilateral triangle (or square).
There are different approaches to plan a release. One is mentioned in the book. It is based on user stories estimation, iteration length selection and velocity estimation but I'm little bit sceptic to this approach because you don't have simple user stories for whole release and estimating epics and themes is inaccurate. On the other hand high level feature definition is exactly what you need for three forces. If you don't have enough time you will implement only basic features from all themes. If you have more time you will implement more advanced features. This is task for product owner to correctly set business priority when dividing epics and themes into small user stories.
The most important part in agile is that you will know more quite soon. After each iteration you will have better knowledge of your velocity and you will also reestimate some planned user stories. For this reason I think the real estimate (accurate) and realease date should be planned after few iterations. As I was told on one training effort should not be estimated, effort should be measured. If anybody complains about it show him Waterfall and ask him when will he get relatively accurate estimate? Hint: Hardly before end of analysis wich should be say after 30% of the project.
It is also important what type of projects do you want to implement using agile / scrum and how long will project be. Some projects are strictly budget or date driven others can be more feature driven. This can affect your release planning. For short projects you usually have small user stories and you can provide much more accurate estimate at the beginning.
This is a very loaded question, and depends on your company to be sure. I first have to ask, why are you using 3 environments and continuous integration (your reason matters)? Are you performing automated tests at all? How are your code branches setup? Do you release for some functionality, or just routine maintenance fixes?
Answering these will give you an idea of why you need a release, and how you should go about it.
For example, if you only have a staging environment for the purpose of integration and perform automated tests, then can't having a separate code branch in which continuous integration tests run be sufficient?
If staging is to perform some sort of user acceptance, does your company have a dedicated testing team or are they members of the agile teams?
As you correctly stated, if the code is always integrated and tested, then why would you need a timetable and moving from environment to environment unless you were unsure about the actual "done" condition of the features? By that, I mean that it's not that you're unsure that the feature was coded correctly, but are you worried it will introduce other bugs? Will it integrate well with code already in production? Address the concerns at the root of the problem. Don't just do it because you think you're supposed to have X environments or testing should be in another group. Maybe the solutions to those problems may be to adjust the definition of "done" accordingly.
As you can see there are many, many factors that will make your organization unique. There is no one right way to answer this, just tradeoffs that you are willing to accept.
I find that having multiple environments with teams of people working at the various layers tends to be anti-agile and counterproductive. The best bet is to analyze your concerns, and try to find ways to solve them (such as expanding the definition of "done", or breaking up the various organizations and putting them on the teams, eliminating as many environments as possible and simplifying the process, etc). That may not be possible in your organization, so you may have to live with tradeoffs.