I am trying to understand why DevOps does not allow start/finish dates for Requirements (CMMI process) as opposed to seemingly just Features and Tasks? In addition, it's odd that if I add a Requirement to an Iteration (which has dates), I see it on a Delivery plan:
I can move it out of the sprint by dragging the start date and end date out in the Delivery Plan,
But don't see any date information on the ticket itself?
The idea is that since Epics and Features are likely to span sprints, you'd use these dates to build a plan. But Requirements should be small enough in a sprint and would take their dates from there.
The start date and end date of the Requirement (comparable to a User Story or Product Backlog Item) are automatically filled when a Requirement is put to In Progress and Done. The Delivery Plan has no direct relation to these fields, hence why the fields are read-only.
Remember that Delivery Plans works the same across the Agile and Scrum and CMMI templates, as such a number of assumptions are made about your delivery process: you work in sprints and work performed in a sprint is generally finished within the sprint.
Related
I am a PO leading a small development team for enhancements to our PeopleSoft Campus Solutions application for a Medical School.
We are using the Sprint functionality in ADO to assign stories from our backlog to the Sprint, create the relevant tasks for each story (mainly development, testing, deployment) and assign the tasks to resources who, in turn, provide effort values (original estimate, remaining, completed). We also make sure our capacity is properly set, with resources OOO time and school holidays configured to get an accurate team and resource capacity. The team updates their effort numbers daily to ensure we are tracking burndown.
While we always start the Sprint with the remaining work hours under team capacity (and the same at the resource level), we have historically left alot of remaining work on the table at the end of the Sprint.
My leadership wants to answer the question "Why was the work left on the table?". Of course, there could be MANY reasons, we underestimated the effort, we were blocked on a task (for example, we can't start the testing task until the development is done), the resource didn't actually have the calculated capacity due to being pulled into other meetings or initiatives, or (and I don't think this is the case) people were just plain lazy.
What reports/analytics can I leverage to help answer this question? Even just seeing a list of remaining tasks per resource with remaining task effort and with a total amount of work remaining per resource overall would be helpful, but I can't seem to find anything.
Any suggestions or guidance is appreciated!
You can use Queries to find the remaining tasks(add column option->Remaining Work) and save the query into Shared Queries.
There is a query results widget in dashboard to display the query in Shared Queries. Do not forget to add Remaining Working in widget.
Remaining Work:
You could refer to the document: Adjust work to fit sprint capacity
I am trying to come up with n Azure Board query to return the work I have performed during current sprint - which I am vaguely defining as:
Work In Current Sprint = [A] + [B]
where
A = work items where I completed development stage (or was decided at some point work is irrelevant) and
B = work items I created in current sprint, not necessarily assign to me nor my team (I spent time investigating an issue, and ended up, for instance, finding a bug, so I want this included in this "report").
The closest I could get is the query blow. Problem is it is still not quite accurate, since with regards to items I created during this sprint - I could not find a way to filter created items in this sprint only - results are showing up work items that CURRENTLY BELONG to current sprint, but not necessarily created in current sprint. The only way I see I can achieve what I want is using CreatedBy - but this only provides a "hardcoded" date range offset, at any given time. If I use an offset of 14 days backwards, running query at the last day of the sprint (considering a 2 week sprint duration) should work, but running the query at any day before that, during the sprint, will return stuff created in previous sprints.
I want this query to help me track "work I have performed during current sprint" (as defined above) at any given day within the sprint.
Any better ideas ?
You could use custom date in 'create date' to limit the work item.
And I notice you use 'work items and direct links', then you need set filters for 'Filters for linked work items' part(as you needed, like iteration path etc.). Otherwise it may return linked work item that belong to other iterations, according to the filled filter, like something belows:
I hope it could help.
My organization is trying to find an out of the box way with Azure DevOps to see which features were 'committed to' at the start of the release, and which are delivered. The Velocity report would be perfect, except Features are assigned to areas that are configured to run off of sprints that are child-iterations of larger release-iterations, and we want the data at the release-iteration level.
We're able to build queries that can mostly deliver this, but that method doesn't track changes, just shows you a current point in time view of how things are.
The goal is to have data we can use to evaluate if we're making commitments we can keep.
How have other organizations tackled this sort of problem? How do you tie committed vs. actuals at the Feature level?
I could understand your requirements. But based on my test, Velocity Report has some limitations:
For example:
If the Iteration Path has Child Iteration, it will show the child Iteration on Velocity Report. As you said , release-iteration will not show in the Report.
So it cannot meet all your needs.
I tested some related extensions and existing charts, and it seems that there is no tool that can improve or replace the Velocity Report .
For a workaround:
For Child Iteration, you still could use the Velocity Report to record the process.
For the Parent Iteration, you could create different queries to show the process(Planned
, Completed,Completed Late and so on). You can use query to get the work item list of the corresponding state.
Here are examples:
Planned :
Completed:
...
Then you could add them to the Dashboards(Query Title Widget):
On the other hand, this requirement is valuable.
You could add your request for this feature on our UserVoice site, which is our main forum for product suggestions.
Our teams are using Azure DevOps. We're using the Agile framework and an enterprise release management approach (essentially, SAFe). Our increments are based on the quarters of the year -- for us, this equals 6 sprints.
My goal is to be able to view work scheduled within the current increment as the sprints move along.
I currently have a query that displays current sprint plus the future 5, to give me 3 month's worth of work (see below).
The trouble with this is it has to be edited after each sprint so it only displays the current increment's work. (I have to change it to include the previous sprint and reduce the number of future sprints otherwise it doesn't display completed work in this increment, as well as showing upcoming work from the next increment.)
Increment Planning Query
Sorry for any inconvenience.
I am afraid there is no such increment planning query, that because the value of CurrentIteration will be different due to the change of the current date.
If you want use the #CurrentIteration macros, you have to modify this query after each sprint.
As workaround, you could specify the each Iteration value in the query, like:
With this workaround, we do not need modify the query after each sprint, just need update it after each quarter.
If above workaround not work for you, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps:
Hope this helps.
We have a small group < 4 but work on several different applications that we support. Each application gets its own Git repo, but as for managing the effort I really don't want to setup a separate team as well for each product.
Questions:
- For a small group working on several different products (eg. websites, services, utilities etc), can a single "team" within one project allow us to work on 2 sprints at the same time that are within different area paths?
- If I have already defined multiple teams, can I migrate all the content into the backlog of a single team?
- Assuming one team and multiple area paths, the project "hierarchy" would look something like this, correct?
Project
|__Team
Area-1
|__Sprint 1-n
Area-2
|__Sprint 1-n
Area-3
|__Sprint 1-n
[ update ]
On further inspection looking at the docs, the iterations can have their own paths. It seems that if we want to manage 2 or more simultaneous sprints or overlapping sprints that involve different products, it makes sense to go ahead and configure a team per product or possibly one team per "business area" (eg. Sales, Operations, Warehouse etc). Within a business area, our group would only have 1 active sprint at a time, which seems straightforward, compared to trying to manage multiple sprints within the same team.
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-iteration-paths-sprints?view=azure-devops
So the better approach might be multiple teams, with one (default) area per team and a iteration list for each team.
The Team's areas and the Team's iterations are disjointed. I would think you could assign the different product areas (websites, services, utilities) to the team but then have just a single iteration list instead without trying to segregate the iterations by area. This won't work if the sprint dates for the different areas are different, but if they are different I don't think any approach you try to leverage in app will work.
Areas:
Sandbox
|__Team
|___Websites
|___Services
|___Utilities
Iterations:
Sandbox
|__Sprint 1
|__Sprint 2
|__Sprint 3
I don't think you will get to a good solution if the different product areas have different start/end dates for the sprint even if you could make something workable using the tool.