Last year, we identified this issue in the card hierarchy linkage feature. Adding parent and child relationships was a bit of a pain as the user had to navigate away from the board to create or edit a card hierarchy. So we introduced the parent/ child bulk link option, using a panel at the bottom of the user’s screen while they are on the Board view and provided the option to add parent/ child links in a single click.
SwiftKanban has a new look. With the launch of version 4.0, we have not only improved the overall functionality and usability of the tool, but have also released the much awaited new User Interface. We’ve implemented a lot of changes based on your feedback. We have introduced couple of refreshing yet vibrant UI themes for SwiftKanban that will not only enhance the visual appearance of the application, but also make your viewing more experiential. The new UI brings to you distinctive color scheme options, meaningful icons, better card designs, full screen view, and lots more.
Hello Folks! We thought we’d begin the new year with a few features that will improve the experience for you in terms of usability. You can now move multiple cards with a single click. Just right-click on any lane header to archive or move all cards in that lane. CTRL + click will let you select a set of cards and right-click will let you move only these cards selectively. Continuing with our theme of adding more configurability in SwiftKanban, you can now customize the appearance and order of Card attributes as they appear on the board.
That was the question posed in a recent discussion. The question further provides the following details – “I work within an agile team. We have a released product and we are still working towards a future release. Every sprint we receive anywhere from 0 to 5 tickets to fix bugs in the released product. Our team is composed of software engineers (to handle new development) and maintenance software engineers ( to handle tickets). My question is how do you account for the maintenance hours during sprint planning. Currently we have a story called maintenance buffer where we allocate some hours to solve tickets.
Within the SwiftKanban development team, we have evolved our Engineering practices, combining principles of Test Automation, Continuous Integration and Kanban thinking. At the same time, as we look to hire people for such a development environment, we have found it difficult to get people who understand such an environment, even though we can hardly be called bleeding edge! Hopefully, this post helps in understanding in our Engineering environment. The day starts with a stand up meeting at around 9am. Since we are distributed team across three different locations (3 cities, 2 countries), many of our team members join the call remotely.
At Digité/ Swift-Kanban, we had a great visit to the LeanSSC (now Lean Systems Society) last week in Boston. Having been in the market for just about a year, it is heartening to be recognized and even be told that we are considered one of the top 2-3 Kanban tools that are out there. An exciting part of the conference was our announcement of our support for Scrumban (or Scrum features) besides our support for both iOS and Android tablets.
The term Lean Software Development was first coined as the title for a conference organized by the ESPRIT initiative of the European Union, in Stuttgart Germany, October 1992. Independently, the following year, Robert “Bob” Charette in 1993 suggested the concept of “Lean Software Development” as part of his work exploring better ways of managing risk in software projects. The term “Lean” dates to 1991, suggested by James Womack, Daniel Jones, and Daniel Roos, in their book The Machine That Changed the World.
Software development using Kanban principles has not focused on Effort Tracking (though there hasn’t been a strong position against the same). At Digité, we were practitioners of Iterative Software Development. As part of this process, we emphasized on Daily Effort Tracking (time filing) for several reasons: A) Since we have geographically distributed teams, it helped us get a sense of what happened without chasing individual team members or asking people to send an email with their update. B) A lot of effort based metrics could be accurately computed and relied upon (especially if you have come from the ISO/CMMI world!).
Our Kanban journey began early in 2010 when we decided that we would build a product in the Kanban space that would address some of the basic issues we saw our prospects face in adoption of Agile methods such as Scrum and XP within their organizations that were historically used to doing waterfall or iterative or some hybrid Agile method that combined more than one type of processes. While the presence of established competitors was a strong reason to look beyond the ‘popular’ Agile methods, we also felt a strong appeal for Kanban existed because of its focus on 3 key fundamentals.
Try SwiftKanban Enterprise Plan FREE for 30 days.