In TFS 2015 using the Agile process template, the board for the "Stories" backlog shows only stories, and the board for the current iteration shows all tasks under stories. This makes sense for most teams.
We are breaking down our work into smaller than usual stories and thus avoiding task breakdown, so very few of our stories have tasks. Is there a way to show stories on the current iteration board instead of tasks, so that it looks similar to the higher-level stories board but with only the stories in the iteration?
In the end, I want to avoid a useless board like this:
Have you considered just using the Kanban/Backlog board?
My team don't use tasks at all, all our work is tracked on the Kanban board, we never use the Sprint Board.
Some teams add a "Sprint Backlog" column to show what is planned for the current sprint. Then you can collapse the "New" column until the next planning session.
Related
Foreword: I've searched around on this question a fair bit and found answers which are close to a solution, but not what I'm looking for. So here I am, and I hope someone can help me. I'm relatively new to VSTS, so be gentle (or at least constructive) ;P
The Question: I'm looking for a way to restrict access to specific tickets (NOT by ticket type) that contain NDA protected data, whilst keeping them in the same backlog and iterations as the rest of the tickets related to a project.
We have many different NDA protected customers, so whilst creating a new ticket type per NDA, and restricting access to this, could work, it's not the solution I'm looking for.
Alternatively, I'm barking up the wrong tree, and there is an entirely different and "better way" to support this use-case?
Edit 1 - More info: Let's say I have 1 backlog for a product. It contains only 2 work items. It's important there is only 1 backlog for planning and overview by a product owner.
One of the two work items contains sensitive information only half the development team should have visibility to. How do I keep both tickets in the same backlog and iterations, but hide the sensitive one from some team members?
Thanks in advance for your time!
Regarding permission of work items in a team project, you can set the permission in area and iteration scope, but can’t for specific work items.
So, you need to put these work items in different area and manage permission for this area. Simple steps:
Go to team project admin page
Work=>Areas
Click New/New child, to create a new area.
Click …=>Security, set the permission for the group(s) or user(s)
Click the default team’s settings => Areas
Click + Select areas to add that area in order to show related work items (in that area)
We are using JIRA to work with a team of Developers and a QA team. Currently the 'Dev Team Leader' creates a 'Task' ticket, assigns it to the development member, who work on that ticket and then informs the JIRA ticket number to the QA team, who create a separate QA ticket for testing it. And of the test is pass or failed they inform the DEV team, who either fix it or change the ticket status to 'In Deploy'.
My question is as follows:
Should they create single ticket and use that to do the Development and Testing ? (ie. shift the ticket between the DEV Team and QA Team)
Should the DEV team create a Parent TASK ticket for Development and then assign it to the QA team, who will create a Sub-Task for the Testing and link it to the Parent Development ticket?
Issues:
We need to identify which team member worked on the development
task?
Which team member worked on the Testing ?
How much of tie spent on Development as a whole?
How much of time spent on Testing as a whole?
What is the best way of doing this ?
You only need one ticket or an Issue in JIRA context. Your Project should have a workflow with, for example, the following Statuses: To Do -> In development -> In testing -> from here, the Issue can go in two directions, back to In development if the QA is not satisfied or Done.
When the Issue is moved to the next step, it will/should be assigned to the proper person, i.e. in To Do it's assigned to your project lead or whoever distributes the tasks, In Development it's the developer, In testing the QA, etc.
This is the most widely-accepted way to use JIRA as a ticket tracker. Each transition will be recorded in the Issue Activity Log with the corresponding datetimes, Assignees, etc. You will have access to all the information you've asked for.
It sounds to me like the workflow is in need of granular tracking of development work and testing, where a single ticket (suggested idea) doesn't satisfy.
I found the following design useful:
1. Create a USER STORY that has a set of criteria that needs to be met.
2. Sub TASKS can be created as children of the STORY especially if they need to be worked on by different people.
3. Once all tasks are completed, the USER STORY can be moved to TESTING / IN TESTING (whatever the workflow defines).
4. The QA/QE Engineer then can create TESTS / TEST CASES (children) for the User Stories and and execute them accordingly. Similarly, defects can be filed as BUGS as children of the story.
Ultimately in this workflow the story must meet a set of criteria and level of quality (based on what is acceptable to pass the story for the business) in order to be considered "completed" or ready for release.
I started modifying/developing Rally apps about a week ago using the existing Rally apps provided on the Github repository so far. However, for one of my final tasks I've been asked to recreate a tailored Defect Trend Report App and unfortunately, the source code is not available for the App. I tried to start from scratch but I've ran into numerous errors and am a bit overwhelmed.
I was wondering if anyone had the src code for the app or knew of a way to extract the src code from the existing app. Of course if there is custom code that an individual has worked on that could also help me progress in this process and wouldn't mind sharing it, that'd also help a ton.
I saw that there were a few snippets that could be used from the Hackathon repo, but they're not quite on the mark of what I want to do with the app. I'm just trying to have the existing app filtered by delivery versions (currently filtered by iteration/release).
All help is greatly appreciated.
Thanks fellas!
There is an example of a 'bare metal' chart app in the App SDK 2.0 docs. It should give you the basics on how to do a chart.To get to it, go to the help pages (click on avatar in top right corner) and search for "Rally App SDK"
After that, you need to work out how to select defects from the various releases and do a count of each. There are two ways to do this:
Get all defects in the project you are in (don't forget whether you need to scope down to child projects too) and then do something like _.uniq() on the release field to find the list of releases (or do another request to get all the releases into a different store and use that for names and a count).
Get the releases and then for each release request the related defects.
If you do ask for child projects, you will need to handle all the scenarios of different releases for different projects - can get complicated!
#1 is effectively one big fetch, #2 may be many smaller ones.
You may want to decide whether to count all defects, sum the estimates, ignore those not finished, etc., etc.
Is there a way to change the Rally backlog to show a list of stories with sub-stories as a hierarchy? Right now our backlog makes more sense to just show epic level stories, but it is littered with very granular stories, so it is hard to prioritize at the epic level. Anyone else have this problem/solution?
Rally's backlog is primarily intended as an area to:
Prioritize
and then Schedule
Sprint-sized work products into Iterations. Because Epics aren't schedule-able, they don't show up in the backlog.
You may wish to consider stack-ranking epics from the Plan-User stories page. Or, alternatively, linking your epics to Features in Portfolio Manager, and relative-rank the Feature-linked Epics within the Feature's Story detail screen.
I'd been looking at using the Rally API to create an app to do some simple auto-ranking stories based on specific criteria (at the request of / to help out a couple of our Product Owners) in a drag&drop workspace.
I did this by adjusting the "Rank" properties of the sequence of stories (I made sure to keep the rank values within the same overall min / max range as prior to the auto-reorder). I made a call to the API to update each story's rank individually (in quick succession).
Testing the app, I found that sometimes after running the auto-ranking app, some screens (such as the kanban board) would tell me that "drag and drop re-ranking is disabled for manual rank workspaces" (and the kanban would no longer let me drag & drop, although other screens such as the backlog would still let me drag & drop, and the workspace settings were still set to drag & drop). Deleting the stories, or reordering them on the backlog screen would return things back to normal.
After trying a few ideas to solve this, I figured perhaps if I was updating the Rank on a number of stories in quick succession, the back-end might be getting confused with these (potentially several / concurrent) requests. Introducing a delay between each story's API call has seemed to avoid the problem, and to speed things up, I now update a story's rank in the API only after the previous story's rank update has invoked the "updateComplete" function.
Do the assumptions in the last paragraph above make sense based on the backend ranking? Is there any Javascript API call to update multiple stories at once? (Otherwise I'm quite happy with the solution of only calling the API "update rank" after the prior API "rank update" call has returned ok).
That sounds like you discovered a possible issue with the backend ranking. The warning you were getting stems from the board trying to figure out which type of workspace you are in (manual or dnd rank). Since that setting is not currently available via WSAPI the board tries to figure it out based on its data and sometimes gets it wrong.
Currently there is no fully supported/documented way to adjust the ranks of items via WSAPI. The Card Board component in the App SDK uses special rankAbove and rankBelow query string parameters during update calls (which you can see in Firebug or the Chrome dev tools).
How are you currently setting the Rank values?