There is a roadmap feature in JIRA, through which we can create Epics, user stories and assign start and end date to them itself by simply dragging the horizontal bar in table.
With help of this feature we can perform month-wise/day-wise or quarter-wise planning for any project. Additionally, we can export and share with client too. I require this kind of user friendly feature in Azure DevOps too. I tried integrating a Epics and Features Roadmap Plugin, but its not giving precise results as JIRA Roadmap is giving. Its user interface is very confusing, giving some occasional error message. Plus, it configuration is also very tedious and time-consuming. Can I get better user friendly GUI in Azure DevOps for Roadmap creation?
Please Help. Attached screenshots for reference of both platforms feature. Thanks in advance.
DevOps provides Delivery Plans to review the schedule of stories or features your teams plan to deliver. Delivery Plans show the scheduled work items by sprint (iteration path) of selected teams against a calendar view.
If it doesn't meet your requirement, you could check the existing extensions to see whether there are extensions useful:
https://marketplace.visualstudio.com/search?term=roadmap&target=AzureDevOps&category=All%20categories&sortBy=Relevance
I was thinking it could be ADO, but that would get it confused with a legacy Microsoft data access layer "ActiveX Data Objects" or whatever it stood for... Or DevOps, but that would get it confused with devops in general, and it's not all that much shorter anyway... Is there an official abbreviation or one that has been settled on by the community?
I've seen 'AzDO' used with success and am not aware of any existing conflicts, like with the misused 'ADO' acronym.
From MVP Juan Rafael, as per this slide presentation which seems fairly definitive, slide 43 states:
No abbreviations should be used (especially not ADS). Azure DevOps or #AzureDevOps are the only permitted forms.
As far as i know there is no official abbreviation for Azure DevOps, these are the ones i tend to hear: ADO, ADOPS, VSTS (yep still going strong). but the majority of times i see people just spelling it out fully.
But i'll keep an eye on this thread to see if there will be some consensus reached :P
I prefer ADO over AZDO/AzDO. It should be clear enough of what you're talking based on the general context of your conversations (Cloud vs. . Reading https://en.wikipedia.org/wiki/ActiveX_Data_Objects, ADO.NET is the current technology, so ADO is available again ;-)
In my company we are using a board to present status of the tickets. Something like kanban board but with more columns. So a chit is a ticket that you put on the table, that is drawn on the board. Columns (sometimes split into rows rows) represent status (development, in testing, etc.). Problem is that this is all manual. I am looking for software to help me setup digital one. I would need:
possibility to integrate with jira (board <-> jira)
fully customizable (look of sinlgle ticket, table setup)
drag and drop option
possible free
I am not afraid to write it from scratch (in java) but if there is something that can help me I am open to suggestions.
Regards
You can try SwiftKanban - it integrates with JIRA and has all of the capabilities you are looking for. There is a free version - but for the JIRA integration option, you do need to pay for it.
Your other option might be to try Trello - which is now acquired by Atlassian, the maker of JIRA - and may be integrated with it.
Disclaimer: I work for the company that has developed SwiftKanban.
There are many tools you can pick up from.
As being part of Kanbanzie, I can definitely suggest it. It is integrated with JIRA, drag and drop function is available and you have 30-day free trial. You can also use a portfolio Kanban approach in order to manage multiple project.
I think Workfront and Asana are good options as well.
Good luck.
I'm considering moving my open-source project Flyway from Google Code to GitHub.
One of the features I really like in Google Code's Issue Tracker is the ability to vote and sort issues by the number of votes. This has allowed me to get a good feel of where current pain points lie and what the community feels needs attention or further work.
How can I achieve something similar on GitHub? Is there a way to maintain a democratic approach to Issue Tracking?
There is no built-in ability to do so. Technically speaking, you can only manage issues by
assignee
tags (called labels at github)
milestones
While you can define label systems for lots of differentation criteria like
bug/feature request/...
prio high/low/...
status verified/unverified
it is simply not possible to have something that accumulates votes. So typically you will see "+1" postings as in good old mailing lists. I've seen people using external voting systems (like Google moderator) for issues on github, but that doesn't make a good user experience either.
If you're willing to use a third-party system that integrates with GitHub, you can try GitPoll.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We use Trac as our bug tracking / development / wiki system and I was wondering if anyone has experience and uses some of the Trac Agile/Scrum plugins or functionalities? Anything you'd recommend?
Or would it be better to duplicate Trac tickets as dead-tree user story index cards and a hand-drawn burndown chart?
Note that I found a similar question here. Though it's specifically about Scrum. They recommend Agilo. Has anyone tried Agilo yet?
With a collocated team, I'd always duplicate user stories on index cards. A wall of cards is much more collaborative and simple to use than any software tool. And what's most important, it's in your face.
The same is true for a burn chart. In my experience, a software chart gets online looked at by a small number of people, and typically is a pull medium. A big, handdrawn poster (that changes regularly) gets noticed by everyone, and serves as an incubator for ad hoc discussions.
It's also quite valueable to be able to point at them during your daily scrum meeting.
This is how we use Trac for our scrum like sprints:
We use the milestones in Trac to identify sprints.
There is a default Backlog milestone where we gather all new tickets.
Before each sprint we move tickets from the backlog the current release.
On the milestone page, we can add retrospectives and other info about the sprint using wiki syntax.
So just the default Trac functionality without any plugins for now to keep it lightweight. As we get better we may add features like burndown charts or maybe switch to another tool, but we want to get the proces in place first.
Answering late, but this more of sharing my experience with Trac+Agilo so far.
To quickly answer your question, perhaps Agilo is the best option available for Agile development with Trac.
Now comes to install and usining install was just very easy. We used their latest release 0.7.3.3. It installs flawless on Trac 0.11 and Python 2.5. Don't forget to install libjpeg and python imaging library. It would be useful to note that we used virtualenv which took a made things easier.
Further usage is very simple. For wiki I kind of prefer Trac's old clean look over Agilo's customization. Other than that all things just works.
On thier mailing list I have noticed that they are planning to offer multi-project support in future. In all I recommend Agilo plugin for Trac.
Yep, I installed Agilo on our Trac installation.
Seems very cool, includes nice burndown charts.
Unfortunately I left the company where I installed it before I could get any serious usage out of it.
Installation was a pain (Ubuntu Ibex) - I documented precise steps on the Agilo Google Group.
The problem (as always) is integration into the business end of things that PMs and CEOs like to see (e.g. estimated vs actual hours). There are (as has been mentioned) other products out there that cover this off (FogBugz covers this off I believe), but I (and the team) love Trac so we worked around this.
Oh, one more thing; it looks like it introduces quite a lot of overhead (i.e. you have to spend more time in trac to get the most out of it), but like I say I didn't have an opportunity to really use it in anger.
We used Trac before with a burndown plugin then went to Redmine. We've found Redmine to be miserable for repository viewing and the issue interface. We're actually looking to move back to Trac again.
Bitten is a Trac plugin for continuous integration that can be harnessed to do automatic builds on check-in, which provides a critical part of the Agile process (rapid feedback). I haven't used any other plugins for Trac personally, so I can't comment on them. However, the native Trac functionality of milestones could be leveraged fairly easily, I suspect, to be used as iteration markers (where each milestone represents the end of an iteration). Since milestones can be used to mark a 'due date' for features already, you shouldn't need much in the way of modification to use them as such.
From there, using tickets as user stories, and tying them to milestones (I'm sure this can be done manually at worst) would give you a basic method of tracking velocity and keeping the team aware of progress (and changes that need to be made as well).
We use the Trac wiki for:
List of requirements for each feature
List of technical specs (if any) for the features
List of Releases and their features
Deployed environments, with links to all instances
There's a macro for making web requests, so we can list which version, etc. each env have
(there's a GraphViz plugin which is quite helpful for simple drawings)
There's also a ticket in the ticketing system for each "feature", for keeping a gross backlog and the current/next sprint planned.
Then we write a bunch of cards during sprint planning for each feature.
There's also a more operational side to things. We keep one person each sprint on Ops, so we have one person who's dedicated to be interrupted by people outside the team. The rest of the team can focus on delivering features.
Each bug/ops task gets a ticket, but as soon as we start working on it, it gets a card and starts moving across the board. That way it gets visibility and we don't forget to involve the testers, etc.
Scrum is pretty tactile, so I don't think it would work great to put too much stuff outside of the physical working environment. But in the end your team needs to find a balance that works.
For something completely different, the best way to do Agile Development with Trac may be to simply migrate everything to Redmine. It supports Trac's core features with some extras including multiple projects, Gantt charts, forums, DCVS, etc. though it looks like it's not completely there yet. Some good things in the pipeline.
Daniel Srb (in the comments) has a redmind agile plugin he's been working on that looks promising. You may be able to contact and see if he's planning to release it (was a long time ago).
We've had success using two products in concert in the past, Trac for tickets, xplanner for planning.
Agilo for Scrum rocks, the latest versions are using client side generated charts, so there is no dependency anymore, much easier to install :-) agile42 just release a Pro version that enriches the Agilo experience with a nice and intuitive Planning Board, very cool screencast :-)
We recently started using Scrumban.
Basically a Kanban board, with the daily stand-up meetings covering the classic Agile Scrum questions - what did you work on the previous day? what do you plan to work on today? do you have any blockers?
We do this around a physical Kanban board, it is great for visualizing the work flow and for team synergy, but we also wanted a digital form of our Kanban board to be able to double check trac usage vs. the physical board.
In search for something that would work, I found this clever post on re-creating a digital version of the Kanban board in trac.
It is very straight forward and simple, I was able to easily manipulate this approach for our work flow, and you could probably tailor it to your Agile Scrum iterative approach (or if your able to ditch the time boxed approach, give Scrumban a try).