Background: A person I work for has her TFS set so that her ToDo, Impeded, InProgress, and Done columns show two items wide in each. The number of tasks has mushroomed recently as management wants to track work at a finer level of granularity.
I'm thinking this is an individual option set (or loaded) on her PC. I've gone through as many of the configuration options that I have access to. This might be something that she has special rights to (she is an software development manager and I am just a scrum master)
Microsoft Visual Studio Team Foundation Server Version 16.131.28106.2
Question: The standard view I have had in TFS and Azure DevOps allows for a single item in each column. What do I change/load/configure/sacrifice in order to get a two wide listing in the columns on my work board?
Thanks for any ideas, help, etc.
According to your description, it seems that you want to Split columns on your Kanban board to show work in progress.
In your Boards >> Setting >> Columns. Enable the Split column into doing and done to make the columns show two items wide in each. Please notice that, you can’t split the first and last columns(To Do and Done). Since they are always mapped to the initial and last state.
Related
I am to set up Jira in my organization and there arise some questions, for which I could not yet come to a, for me convincing, decision... may you give me your opinion, what the best configuration would be?
(I will be talking here about projects but it might be found out, that should later be boards or whatever)
I have requested my org the creation of a Jira account for my department, and as seen from the settings, I got created a Board associated to me as an admin
We are a team of 15 people in the department
We want to start setting 10 different projects, some might be related to the other ones but still keep an individual sense, thus, each should have its own Backlog
The scheme of the projects should all be the same (notifications, workflow, issue types...). Ideally, if changing something lately in the scheme, all projects should actualize to this automatically
We will be all teammates allowed to work on all projects within the department, always, no restrictions
We want all to be able to check for the statistics etc. related to any project in the most easiest way
Users want to have on their board (screen) all projects and tasks, in the order planned for them to be performed, don't matter if they belong to different projects. Desired view would not be a flatt Kanban but issues being classified by Project > Epic > Sprint
The ideas I came up with are:
(1) Me --> Board --> 1 JiraProject --> n Epics (each = OurProject)
Having just one project (namely, the name of my department) and then create one Epic for each "real" project we want to handle. Then, to each Epic create the Issues related to each of our real projects. The problem with this is, that we would need a second level of Epics to suborder into each of the main Epics (representing our real projects) so that we can group their issues into logical parts of the project. This second level of Epics seems to me not to be possible. Additionally, this approach will just provide us with one Backlog common for all our projects (here provided as Epics).
(2) Me --> Board --> n JiraProjects (= OurProjects) --> each JiraProject
This seems to me to be the best approach, but has the inconvenience, that when a person has to work on several projects he has not the insight of the order of the tasks he has to perform, nor if any of these collide in time with any other of any project.
I ended up creating a single Project with a single Board.
In Project Settings (left side panel, bottom):
I enabled Components to appear on the left side panel
I set Issues to show the field "Component" when they are created
The Jira logical classification will be now like this:
PROJECT is my department
BOARD is the common view all users will share
VERSIONS are Versions
EPICS are my different Projects
COMPONENTS are now a kind of Epics for my projects, but with the disadvantage that:
a) they are all shown in a separately view, not as a side panel similar to VERSIONS and EPICS
b) they are all listed straight forward, which requires to give an identifier at the beginning of their name to differentiate to which Project they belong to
USERS: all Users will manage to see the main Project (which is my Department) and inside of it, all the Epics (which are my Projects). This was initially my requirement, so it is ok.
I wish Jira was a bit more flexible on letting us creating some additional group categories similar to VERSIONS and EPICS, so that we could get and extra group layer.
The use of Components here is not really very useful, but also confusing and not intuitive, but is the only option available at the time of this post to extra group somehow my Issues.
Problem:
Customers that become access granted, can access and see all or projects, what is naturally not good!
Our development team is upgrading to TFS 2015 and we're able to start our Work item tracking from scratch, so I'm looking to take advantage of this to re-organize some of our current processes.
However I can't figure out a logical way to organize the iterations across multiple products, here's some background on what we do today
- We have 1 small team with 3 developers, and we all work on 3 different products concurrently, desktop, web, and mobile are the 3 products and they're all closely related owned by the same client
- I have TFS setup as 1 large team project as I've read this is the best way to organize work rather than separate team projects
- Each product has a different build number so we can identify different release versions for each product
Things I've tried for iteration organizing:
- Iteration number for each product (desktop/build1.1 mobile/build3.1 web/build4.1) This doesn't work because I can only set one of these as the 'Current' but in reality we're working on all 3 of these at the same time
- Single iteration number (root/build1.1) this also doesn't make sense logically for us because 1.1 only applies to one of the products, when I create a build for the products they will have different build numbers that won't match TFS. Also not all 3 products are released every time, so even if I used a single release number for all 3, there'd be gaps in the release version numbers for the products that weren't updated in the current release
- Child iterations, I can put mobile/build3.1 as a child of desktop/build1.1 for example, but it doesn't display this way under 'Current' so we wouldn't visually see that the current release will include mobile3.1 items also
- I've read that we can create separate teams for each product, but then we would have to switch dashboards to see the current build for each product. This also feels strange since it's just the same 3 people working on multiple products
My goal is to for us to be able to see each different product release number that has current items assigned to it in 1 single place, can anyone suggest a way to organize this?
I don't feel that Iteration Path is the way to go here, nor is multiple teams. Use Iteration Path to track your team's sprints and keep to a single team as you are a small team as it is.
There was a Similar question a few days ago which was well answered by Jesse Houwing.
Tags may be the simplest way to go but you might find creating a custom Work Item type (Release) that you can link to the Backlog Items is better or perhaps just a custom field on the PBIs.
I have two project setup, both using the Scrum template. In one of them the sprint backlog board shows swim lanes/columns as I would expect:
To Do
In Progress
Done
In my other project (the one that matters, of course), it looks as if the columns from the Backlog Items have been merged with those of the Sprint Backlog items and displays with all of these columns:
To Do
New
Approved
In Progress
Committed
Done
The extra columns appear to be read-only in the board view and do nothing but make the board cumbersome to use. Have I changed a setting somewhere that affects this?
You probably have one team (or project) configured to have bugs on the backlog as requirements, and another team/project configured to have bugs on the backlog as tasks.
Bugs have a different set of states, so if you treat bugs as tasks, the board will show two sets of states: One for bugs, one for tasks.
This can be configured by going to your team's settings (click on the "gear" icon on the top right in VSO, then Overview tab, then choosing the team and looking at the settings).
Daniel's answer pointed me in the right direction, but it still wasn't clear exactly what steps to go through to fix the issue. Here are step-by-step instructions on how to set the number of columns on your sprint board based on how your team works with bugs.
Note that this is a modification from my original answer. The way to fix this has become dramatically easier after the latest update to VSO.
Click the gear to edit settings on the sprint board:
Click Working with bugs under the general heading in the left column.
The option you select here determines how many columns appear on your sprint board.
I'm looking for a work-item-tracking/bug-tracking system (or JIRA plugin, or TFS plugin, or...) which makes it easy to stack-rank work items without having to manually assign priority values to each work item.
Instead, our team wants to be able to see a list of open work items and be able to drag-n-drop one or a multiple selection of work items until the order matches the team's prioritization. This would be much easier than arguing about priority numbers and dealing with ties (e.g. "which of the 5 bugs marked priority=2 should I work on today?").
Our team is considering switching work-item-trackers (we use Gemini now) and availability of a good drag-n-drop prioritizer is high on our requirements list.
I realize drag-n-drop ranking is non-trivial because no team will stack rank all work items. Instead, we'll want to take a subset (e.g. work items for one sprint sprint or iteration, or bugs assigned to one developer) and stackrank those, then later look at a different subset and stackrank those, etc. And I'm sure we'll sometimes need to mix and match different stacks, so there'd need to be heuristics (ideally configurable) about how to show a stack of items previously stacked separately.
Pivotal Tracker is close to the drag-n-drop UI I'm thinking of from a UI perspective, but Pivotal's model of separating user stories from the underlying work items (plus a few other issues) doesn't match how we want to work. We don't want to have to deal with different artifacts (stories vs. JIRA/BugZilla work items)-- instead we just want a drag-n-drop UI to automatically fill out a "priority" field in the issue tracker, and which we can use later when sorting and filtering. And we wouldn't want to use Pivotal as our only work item tracker, because it seems to lack common features like bulk editing which are critical for large projects.
Anyone know of a tool like what I describe above?
Urban turtle is the best TFS add-on, making ranking/prioritizing a sane activity. Priority by number is a disaster so don't think you're alone there.
http://urbanturtle.com/
Urban Turtle is updated every month and used by quite a few teams including a number of my teams.
Eylean Board has what you are looking for. They offer a task board where the tasks are prioritized by moving them around, the priority tasks being on top. Interface is nice and clean and they offer other features such as integration with TFS, reports, etc.
The greenhopper plugin for JIRA has this feature. It's worked well for me ...though I'm not a big fan of JIRA in general.
http://www.atlassian.com/software/greenhopper/tour/backlog-management.jsp
Previous to this, I just used excel.
One of the best (and fastest) web UI's I've seen is on AgileZen, which supports something similar to this. Last I knew it did not have built-in integration with TFS, but it does have a REST API. It's basically a web-based, shareable Kanban board.
We are using VS 2010 and TFS 2010 with the Microsoft Scrum Template.
We use the Team Queries for the Current Sprint like the Sprint Backlog query.
The problem is when we move to sprint 2 the "Current Sprint" still points to sprint 1.
Is there a way to to tell TFS that we are now currently in sprint 2 and have the queries use a variable to run against instead of hard-coding the sprint?
For example: If you look at the screen shot below you will notice that the definition of the query uses a variable called "#Project" for the team project. Is there a way to have a variable for the sprint?
Tom,
What you are asking for is not available in TFS 2010. There are not even dates on the iterations, so TFS does not know what the current iteration is.
In TFS11 (vNext) we have added the dates on the iterations. It now knows in which iteration you are, and this is also reflected on the backlog page in web access. In the preview version that is out now it is however not possible to add a filter clause to your queries to filter on the current iteration (something like #CurrentIteration). We have heard strong feedback to add this in the product before it ships. It is also very high on our wish list, but we need to fix other things first before we can ship.
You can add this request on User Voice. If the idea gets lots of votes it makes it easier to build a case that we need to put this in. But we cannot promise anything.
Ewald - TFS Program Manager
Almost all answers here say that you either need to wait until Visual Studio implements #CurrentSprint token or to change all existing queries manually.
I found another great practice that might help you which is explained here:
http://intellitect.com/transitioning-between-sprintsiterations-with-tfs.
Try to create a “release” called “Current” and move the specific current sprint under it. It's much easier and quicker than dealing with queries every time you start a new sprint.
You could modify the work item query programmatically: http://www.ewaldhofman.nl/post/2010/03/09/TFS-SDK-2010-e28093-Part-6-e28093-Replace-text-in-all-Work-Item-Query-Definitions.aspx
I've only ever read documentation/guidance (links unavailable at the moment), that said at the start of a new sprint there are a few various steps you need to take in TFS, e.g:
create the new sprint/release nodes
set the applicable PBI work items' iteration to the current sprint
set the applicable PBI work items as committed
update all the "Current Sprint" queries to reflect the new sprint number.
I've never seen documentation on doing the last step list (or any of them) in a hands-off (automatic) way. That said, I'm not suggesting it's not possible, just stating that I've never seen guidance on how to do it, but have seen plenty of guidance on doing it manually.
You could use a plugin called TEK workitem. TEK workitem is a Visual Studio extension for TFS that allows bulk edit of query definitions, besides other features like open in Visual Studio workitems and queries from a Hyperlink, delete Workitems from Visual Studio UI, etc.
You can download a demo from Visual Studio Gallery: TEK workitem
I am pretty recent to TFS Scrum 1.0 but this is what I do.....
I am currently managing my sprint dates outside of the template
I use the 'Current Sprint > Query’s' to give myself and team quick access to the queries on the current sprint.
When I finish a sprint and want to increment to the next sprint and have the queries under 'Current Sprint' point correctly I do the following:
Edit each query under ‘Current Sprint’
Right lick and select ‘edit query’
You may see an error dialog if you have changed the hierocracy of your iterations. OK to click through to the query editor.
Set the value of ‘Iteration Path > Under’ by selecting the correct sprint from the drop down (populated with your iterations.
Save the query and bob’s your anty…. Queries will display you current sprint. Just repeat each iterations.
Hope this helps....
I found in TFS 2013 that if you uncheck the sprint/iteration the one with the earliest dates get assigned to current automatically. If you want to keep the old one visible, move the dates out a year or so and it drops to bottom of list, but out of scope.
This is TFS online 2017
Step 1) Settings-> Work->Default team settings
Step 2) and then 'Default Iteration'->Change
Keep in mind that next time you might be starting in Step 2. So Step 1 is optional.