We began using this product in 2014 as a work management tool. After that, we gained knowledge of the Agile framework and implemented these features in Rational. We now have five scrum teams, all of them using this solution for scrum planning. This includes dashboards and the Kanban view in order to support them.
Application Lifecycle Management (ALM) Suites scrum Reviews
Showing reviews of the top ranking products in Application Lifecycle Management (ALM) Suites, containing the term scrum
IBM Rational ALM: scrum
They should have design patterns in TFS for the development team, and design patterns for the QA. QA around the world basically does the same thing, and also development. Similar to Scrum, they should have something already built-in.
I would like to see templates for design added, and the option to make it more complicated.
reviewer1334121 says in a TFS review
Technical Delivery manager at a insurance company with 201-500 employees
We mainly use it for source control.
In the past, I've used it throughout the whole CI/CD. I've worked with Scrum and Agile methodologies. From the user story, from the product backlog to the CI/CD and deployment. I've used it for everything — the whole nine yards.
At my previous company, there were a lot of employees using this solution; it was the only system that was being used.
I have also worked with Jira.
I come from a QA background, and we used to do automation. Jira was far easier to integrate with our QA automation frameworks because it has a large number of exposed APIs and public APIs that we could use, which is a positive development. Also, the burndown charts, as well as the ability to manage different Agile model frameworks, where we could use scrum in one project but also had to use Kanban. As a result, the transition from one framework to another was simple. These are the things I found useful but haven't seen in the case of TFS yet.
reviewer1727481 says in a TFS review
TitleSpecial Education Teacher at a educational organization with 201-500 employees
It has been really dated. When you start to work more in an agile environment, it is not really that flexible. They tried to replicate the look and feel of Jira, but it is not quite there. It was nice to use in the past, but it is not as flexible now with the changing development environments and methodologies.
It should have some of the things that Jira has, such as boards. We're focused on the scrum boards where you can actually drag and drop work from one queue to another. There should be more flexibility where you can just drag and drop as a user and have more visibility about what's active, what's not, and what's assigned to you through dashboards.
We use Jira to manage scrum projects for the different projects in our company. Our business is a development company that uses the cloud version of Jira to manage the sprint and releases for each project for each client. We manage scrum and cascade projects with our clients.
We have a development team and we use Jira to manage our projects. We use several products by Atlassian whenever we create and work on a new project.
We have scrum masters who write new project stories, which are tracked by Jira.
The solution offers up great transparency that makes it possible for everyone inside the departmental organization to see what's happening.
The prompt board really helped us out on projects. The scrum boards and the representation of the product backlog that helped us a lot as well. It's great for project management.
There are a lot of different plugins for Jira. Unfortunately, we did not test so many and the big pain point for us is the rigorous handling and the roadmap of Jira. We have a portfolio and structure plugin and we have our story map plugin in Jira. I am a scrum master and coach in my company. My colleagues aren't so educated on these plugins. So first we have to improve all knowledge with these plugins in Jira, to improve or efficiency in the roadmap and for these topics.
software923448 says in a Jira review
Agile Software Architect at a computer software company with 11-50 employees
I am the software developer manager and I use Jira to manage team performance. We're also starting to use Jira for our drives. I used Jira before, for creating user stories from boards, to discuss issues, and many other tasks. Today we use Jira, Confluence, and BitBucket in our work. We practice scrum in our organization.
reviewer1322850 says in a Jira review
Technical Lead at a mining and metals company with 51-200 employees
Virtually every day we have our daily scrum. Our team gathers around the board, which has all the columns showing where the tasks are standing: requested, planning, ready-coding, review, etc. Together, we view one task after the other and update the statuses. It's really a focal point of the team to know where the work stands, and what's the progress of the work since the last time we checked.
Within my company, there are roughly 25 employees using this solution. We have a scrum master, who's the most knowledgeable person on the tool. usually, they're the ones organizing the tasks, creating new tasks, and then creating the report at the end of the sprint or the quarter. They're the person who's creating the reports, using the more advanced features. That's the scrum master.
There are the developers, including me as a tech lead. There's the tester. There are managers — once in a while we have to present them with some reports and statistics, so they know how much work is being achieved, but they don't have in-depth knowledge of the tool. It's really an internal tool, so the customer is not involved.
We're not expanding much at the moment. We've been expanding in the past year, but now things have slowed down a little bit due to COVID-19.
I use it for project management and agile scrum projects. I am a manager, and I work with backlog tools and sprint plans. I only use Jira for backlogs, sprint reviews, and data reports. Our project manager is the person who is really working with Jira along with the team. We also have Confluence and Bitbucket. We use CloudBees and DevOps for the deployment of the environment.
The solution helps a lot with scrums.
It's great for development.
The documentation is quite good.
It has some automated software testing which is useful.
reviewer1481571 says in a Jira review
Manager at a computer software company with 201-500 employees
I would definitely recommend Jira for project management and similar uses, as well as other products from Atlassian like Bamboo.
Jira isn't what you would call a "coded solution" for scrum or anything like that, but it's able to do a lot of different things for people who are looking for that kind of thing. If you are looking for a custom-made solution specifically for agile or scrum, then you can go try other products like Valley or others. But if you want a good general-purpose project management system with solid integration solutions like Bamboo, then I think Jira is the product for you.
I would rate Jira an eight out of ten.
reviewer1490121 says in a Jira review
Director at a computer software company with 10,001+ employees
My people use ASS. I can define spins, I can define roadmaps, I can define components, I can do releases, I can define all kinds of issue types, heartbeats, some of those things. I'm using it for both business and software. In software we have Scrum and Kanban onboard, whereas for business we have the service and then there are those other options. We have multiple use cases. I'm the director of the company.
I would recommend this product. Overall, it is a good product. It supports scrum and agile developments. It has a lot of benefits that can be applied very quickly in organizations.
I would advise others to do a test installation and make sure that it fits their needs. Experiment with the multitudes of features that it has. I know there are lots of modules. There are probably many features that we are not using.
I would give it very high marks. I would rate Jira a nine out of ten. There is always something you could improve on it.
The sprint tracking is really helpful and very convenient.
Scrum boards are very easy to follow and we use them every day.
The roadmap, to understand what our team is going, is quite helpful when it comes to understanding things in a visual format. It provides good visuals such as the Burnup Chart.
Requirement traceability is easier to do with this product.
It integrates well with other tools.
reviewer1407036 says in a Jira review
Senior PM / Scrum Master at a financial services firm with 1,001-5,000 employees
I work with a credit rating company in the US. As a scrum master and project manager, I have to make sure that all the impediments are removed for the team. I work with product owners to make sure that all initiatives requested by our stakeholders, who are mainly compliance and regulations people, are moving in a timely manner.
I use Jira to make sure that we are capturing all the work that is requested, and it is progressing in a timely manner. I am in charge of a squad called Core Operations Reporting. A squad is usually focused on one or two initiatives. The goal of our squad is to automate regulatory reports as much as possible. I talk to our stakeholders to ensure that any errors in credit ratings are dealt with in a timely manner. A lot of these requests are ad hoc, and we prioritize them in sprints in Jira.
The thing that I do like about Jira is that it is relatively easy to understand. In some respects, you don't have to read a lot of ticket information, and you can start pulling down. Everybody is using it, and it works for a lot of people who are just doing enterprise development, cloud-based development, and things like that. It is built for the general audience.
It is a good defect tracking tool. It has a lot of capabilities and functionalities. There are a lot of graphs and a lot of tracking. It can be sprint-driven if you want. There is a lot of data that you can pull out for estimations. It has got a lot of out-of-the-box functionalities that are kind of like the Jazz platform for out-of-the-box scrum and other such things.
It also works well with all the integrated tools that you buy.
reviewer1465254 says in a Jira review
Software Engineer at a tech services company with 1,001-5,000 employees
Our primary use case is for project management, guiding the teams in our company. The solution allows you to create Scrum boards to deliver all the acquired stories within the Scrum Sprints. It also adapts to any other Jive methodology, like Kanban, and helps the creation of roadmaps for the software, production and implementation. We use it for day-to-day tasks, managing our stories, assigning tasks to different developers, and even integrating it with other system control tools to link the story's details. We are customers of Jira.
After purchasing Jira, we started shifting to it from the older software we used, like Bugzilla. Bugzilla was being used as our bug reporting tool but after the introduction of Jira, we began to use several of its features. We now use Jira for Scrum Planning, Bug Reporting, Time Tracking, and Budget Tracking.
Day by day, the transparency of the project improves and estimating the project release date becomes easier to do. It is also easy for management-level users to check the project's budget and estimate the release date for a specific feature.
Because there are a number of charts available, looking at them will assist you with any decision that is related to your project.
reviewer1629909 says in a Jira review
Sr Consultant at a financial services firm with 1,001-5,000 employees
The solution can scale well. it's pretty straightforward if you need to do so.
We have product owners, project managers, and scrum masters on the solution. I would say that we have a thousand people using it, however, I'm not saying that for sure, as the bank has 46,000 employees and I'm just a part of a small team. I'm estimating that I would expect over a thousand people to use it.
It's a Scrum tool, so it's very easy to use. That's what I like about it.
You can very quickly create a new project, add stories, and then make them into a sprint. It's very user-friendly.
Jira covers everything for project management and life cycle related items. It's a fine tool to work with.
I have not seen any issues with stability or scalability.
I use it to manage my scrum projects and some of the Kanban projects.
In terms of version, they have been updating it every three weeks. It is a kind of a sprint that they do, just like Google Chrome. So, there is no going back and forth. We use a cloud-based application. So, it is always the updated one.
The type of cloud depends on the client. I've been through all kinds of situations: completely public, semi-public, and private. If it is a public cloud, then it is directly from Atlassian. They are providing it. So, there is no middleware.
I'm from a QA background and we used to do automation. It was far easier to link JIRA with our QA automation frameworks because JIRA has a lot of public APIs that we could use. Also, the burndown charts and the ability to manage different frameworks of the adjoint model are helpful. We could use scrum in one project or Kanban. So it was easy to manage the transition from one framework to another. Those are the things I found useful, but I haven't seen the case of TFS yet.
The initial setup is different and is case by case, however, for a single person or scrum team, it's not too hard. The process is simpler on smaller setups. The more processes the company needs, the more complicated the solution gets during implementation.
We have our own engineer team internally that handles maintenance. We have no problem with maintenance tasks. It's not too hard to handle.
We are using Jira Interview to handle all the facts from clients and schedule calls with them. We have a different operations department that configures Jira, and we have technical people that help us choose the deployment model.
The main reason we are using Jira at this time is for a different dashboard and chart. The major one that we are using is for the stock analysis, and it's nice to get that time log for our team, get the score of the game, 40 points delivered in a week or a month. we are using Jira for following purposes:
Estimation & work logging
reviewer912855 says in a Jira review
Lead Consultant at a computer software company with 10,001+ employees
I like the ease with which we can do our workflow administration, especially with respect to defects. We can do good work with the boards, whether it's a Kanban or a Scrum board. It's much easier with Jira than with other tools.
reviewer1731435 says in a Jira review
Senior Software Engineer at a tech services company with 5,001-10,000 employees
It is a very convenient tool. We can organize our sprints through scrum or kanban. There are scrum boards, and there are kanban boards. If you prefer scrum, you can use Jira. If you prefer kanban, you can still use Jira. You can create your kanban boards in a similar way as you create your scrum boards. It is very useful. It also seems to be very popular these days.
reviewer919590 says in a Jira review
Software Test Engineer at a financial services firm with 10,001+ employees
Likely every single user has Jira as we are fully delivering software with that. It's between three and 5,000 users. It's company-wide and there could be thousands of users. All the development work is documented there. It's used for our agile teams. You have teams that are using agile scrum.
It's very flexible and it supports both ways of working. It's very helpful also with child transformation. The whole organization moves into agile and everybody is relying on those dashboards and daily standups and it has heavy adoption. Everybody's using it.
The solution is easy to scale and that's a bit of a problem. It's highly customizable and you can also destroy Jira by over-customizing things. If you, for example, want to raise a bug and you have 50 mandatory fields, you kind of lose patience with it.
That's not really a Jira problem. That's the customization from inside the bank where there are lots of different requirements being put into the tool and it can destroy the user experience in the end if they over-design it. If it takes you ten minutes to raise a bug due to the mandatory fields. That's really annoying and that's a big problem.
The solution is primarily used in a scrum setting for creating all the features, topics, epics, stories, backlogs, and helps manage the scrum.
Rally Software: scrum
reviewer1568037 says in a Rally Software review
Implementation Consultant at a healthcare company with 201-500 employees
It is kind of set up for Scrum or Agile, but we sort of use it more in a kind of hybrid way. It does help build accountability because, during stand-up, you have to see what everybody is doing, why certain things are in red, and why someone is not where he or she is supposed to be.
Microsoft Azure DevOps: scrum
reviewer1346682 says in a Microsoft Azure DevOps review
Lead Technical Consultant (Information Technology) at a construction company with 1,001-5,000 employees
I like the entire tool because it is a one-stop-solution for DevOps.
The Scrum functionality in project management is helpful, as are the code repositories. It has support for pipelines.
reviewer1260639 says in a Microsoft Azure DevOps review
Chief Digital Officer (CDO) at a financial services firm with 201-500 employees
We primarily use the solution for our Agile teams, however, we started off using it with our executive suite. Our executive team now meets in sprints every day. Sometimes it's a short 15 minutes, other times it can be up to an hour. We have two-week sprints and daily scrums associated with it. We've also rolled that down from the executive. We've got seven formal Agile teams running throughout the organization across our businesses. We probably have at least 40% of our staff now trained in Agile and using DevOps to execute the projects.
We are using this solution for CI/CD projects, for Scrum, Agile planning, testing, and business management system solutions.
We are also using it for continuous integration, and continuous delivery of DevOps.
I am also using the Git Repositories, which is the main source control for me in the organization. We were using it on-premises and now planning to move it to the Cloud.
They are calling it repository and they are supporting an old protocol, which is a popular protocol called Git repository.
reviewer1435167 says in a Microsoft Azure DevOps review
Software Architect at a mining and metals company with 10,001+ employees
We use Microsoft Azure DevOps for application lifecycle management, including source control-related things, pipelines, and also for work item management. In short, the whole ecosystem.
Within our organization, there are roughly one thousand core developers using this solution. We also have stakeholders, product vendors, Scrum masters, testers, and manual testers.
reviewer1544295 says in a Microsoft Azure DevOps review
Assurance Manager at a energy/utilities company with 5,001-10,000 employees
It is pretty straightforward on the administrative side, but I've been working with this technology for a long time. It really falls in line with the majority of Microsoft products. If you're familiar with the Microsoft stack, it follows their pretty standard setup. You go through a similar process. It is just about knowing the nuances that Microsoft has when you're doing a farm configuration or a farm setup and the recommended prerequisites before you get started.
If we're talking about new end-users who are going from an older version of TFS to Azure DevOps Server or Azure DevOps Services, there is going to be a bit of a delta because the technology is different. There is a slight learning curve. Of course, it has got fancier bells and whistles and a jazzier user interface. It has softer edges and things have moved from left to right. Things that you found on the left side have again moved back over to the right side for administrative or usability functions. Your security elements and the things that you used to see on the left side have again switched back to the right side. These are the kinds of nuances about which you would need to educate your end-users. You need to get them used to the boards and how to use those. If your company is transitioning from a CMI model to an Agile model, it is going to be very important for the folks who are administrating your projects and your project managers to know how to configure the projects themselves, how to use Teams, and how to use permissions. Security becomes even more important because a lot of that really influences how you see the information within your project, and how you manage your boards, your sprints, and the work items that you allocate to your scrums or sprint users.
As you're going through different stages of your project, you have your pipelines and repos where your more development-centric users are going to be. I try to allocate out two different kinds of users that we're going to have and target them when I'm educating my folks. You have a kind of power user, and you have your regular contributor user. It is important to make this distinction because there are folks who are going to be doing basic or just regular contributor work. They will just contribute to the work items that are on a board or within a sprint. You're also going to have users who need to be slightly elevated, which is going to be that basic plus test plan. You need to understand how those affect your subscription and billing towards that subscription and how to manage that when they're not actively using it. You need to monitor this and enroll them back to a stakeholder so that you're not constantly incurring costs against your pay-as-you-go subscription costs. Everything is pay-as-you-go once you get into the cloud.
reviewer1561002 says in a Microsoft Azure DevOps review
XBRL Specialist at a financial services firm with 1,001-5,000 employees
I am using it as a developer in the agile scrum area.
reviewer1506549 says in a Microsoft Azure DevOps review
Director of Strategy at a financial services firm with 1,001-5,000 employees
I wasn't part of the conversion from Jira to DevOps but it was a painful process. We lost data, things didn't map. My Scrum Master who used it was not happy with the process.
We are using the tools in this solution mostly for planning our software projects by implementing Scrum. We use repositories, and create timelines for continuous deployments and integrations.
reviewer1589883 says in a Microsoft Azure DevOps review
IT Project Manager at a energy/utilities company with 10,001+ employees
We've only been using it for about three years, and so far, it seems to be able to adapt to our growth. We're maturing into it. We're moving in the direction of using it more, and I feel confident that it'll scale appropriately.
We have at least a hundred people using the tool. There are different degrees of people who are using it. Some people are using it in the read mode or view mode to keep themselves informed of where things are. We have some project managers who actually use the tool, and then we have a couple of administrators. I'm one of the administrators for our program. I have a couple of vendor or partner folks who are also administrators. We also have a development team that does some customizations on the dashboard and the Power BI reports that we do. These are pretty much different roles or layers that we have.
We do grant developers access to be able to make their own updates within the tool. Typically, project managers or scrum masters do that, but we also have some team members who are on these projects and have enough understanding of how the tool works and how we're using it. They are able to do their own reporting and their own updates on their statuses.
In terms of plans to increase its usage, we're moving in that direction. Most of our projects are done in Microsoft waterfall project management schedules, but we are being encouraged to move over to more of an Agile approach on our project methodology. Our mandate is that if you're going to do anything Agile, use the DevOps tool.
reviewer1650696 says in a Microsoft Azure DevOps review
Manager of Information Technology Services at a government with 501-1,000 employees
To run it, to use the tool the way it's designed, you need someone who understands Scrum or Agile project management.
I have used GitLab and other pipeline tools like Jenkins. Azure DevOps combines all of them together, and it beats all of them at everything they do.
On a scale from one to ten, I would rate this solution at nine and advise others to go for it.
reviewer1045596 says in a Microsoft Azure DevOps review
Project Manager at a government with 10,001+ employees
I used to work as an engineering manager, a scrum master, and as part of a technical team. JIRA is my preferred tool for this.
JIRA is a more robust and mature tool. However, as you are aware, JIRA is more modular and requires integration with other parts. DevOps, on the other hand, has everything in one, it combines source code control, release management, and task tracking.
Azure DevOps is user-friendly. The UI and the UX are perfect. Their software covers the whole development cycle, from requirements analysis to deployment. In particular, it's helpful in the requirements analysis phase. You can apply your methodology or Agile framework from the beginning. After choosing the framework, like Agile or Scrum, Azure DevOps provides many features, like user stories, tasks, managing boards, and those kinds of things.
Azure DevOps is complete and meets all of your expectations. You can develop your own plugins to customize it however you want, so it's highly flexible. We develop personalized plugins or use ones that other programmers create for the Azure Marketplace.
This makes up for any possible deficiency in Azure DevOps features. If you want some capability that Azure DevOps doesn't provide, you can develop your plugin or customize any part of it. The options for customization make it worthwhile for any software development.
reviewer1701294 says in a Microsoft Azure DevOps review
Vice President at a tech services company with 51-200 employees
We adopted the SAFe Framework, and more than 10 teams are using the process or workflow template from Azure DevOps for SAFe. Also, we're currently using DevOps for future planning and backlog management following the scrum approach on the team and coordination level. The company plans to extend this with Lean Portfolio Management.
I've been a developer on the backend. In terms of setting up the product, my answer would be highly complex. If I were just doing it for a core user, set of users, then I would say the setup was relatively frictionless. I would say the one point of ambiguity is for some newcomers if they don't understand the difference between CMMI templates versus Agile, versus Scrum, they'll find it complex. I've seen a lot of new users create dummy projects to then go in and see how each of those is configured from a template standpoint. Work could be done there to just reduce that level of friction.
In terms of deployment times, I've been on multiple different sides of levels of deployment. From the simple side, I've seen deployments take as little as a couple of minutes. If it's teams of five, for example, they go into the web app, they start up a new project, and boom they're in. They get all the requirements and user stories and all that stuff done.
I've also been on the other side where it's been nine months with 22 people working full-time to configure and deploy this system across thousands and thousands of users. It just depends on the size.
Planview LeanKit: scrum
We have found that some teams get a lot more requests and work and projects than other teams. Those work-in-process, or WIP limits, are really helpful at determining if teams can take on more workload. It also helps us to see if they have roadblocks. If we have a lot of things that get in our way, it's easier to identify because we have everything in one central location on LeanKit.
Regarding a given card's status, LeanKit gives me easier access. I'm able to work more closely with my team to see what's going on with the cards that they're working on. And my manager can check in on the work that I'm doing just by looking at my cards. Everyone has a better picture of what's going on for the entire team. It also helps in project delivery. We can definitely see if our project is on-time or if we burned down too much time and are getting close to the end of the project and don't have everything done that we were supposed to have done.
While I haven't used the Card Health feature as much, when I have done demos of LeanKit to teams that are starting to use it, and I've shown it to them, they have found it really helpful. If a card has been sitting in the same lane for a few weeks, it helps them track things better to see what's going on with that individual card.
The Card Health activity stream helps business analysts and project managers to identify roadblocks, if they haven't been brought to the surface. If they have a card that's unhealthy, they're able to go to that team member and say, "Hey, what's up with this card? This is affecting the project's deadlines." Or they can even see, "Hey, we were able to get that card to the Finished lane a lot quicker than we thought," and they are able to analyze how that affected the project.
LeanKit has also reduced our cycle times. We are able to stay within our two-week sprints for those scrum teams. And for others we still have better continuous delivery; they are pretty healthy too. I would approximate that we have reduced cycle times by 20 percent, and that's just because we haven't been using it that long.
In addition, our project managers, business analysts, and scrum masters are able to use the solution's reports to determine if teams need additional help or if they can take on additional workload.
reviewer1677390 says in a Planview LeanKit review
Director, Solution Strategy & PMO at Verisk Analytics
With Leankit, our PMO has a single solution and Program Increment Board to integrate teams and projects and align priorities across the entire program - which consists of 22 Scrum teams.
It allows us to track our PI goals, sprint goals, dependencies, and impediments across all of the teams creating extreme visibility and predictability for product owners, stakeholders and the teams. With integration into JIRA and the team boards, it allows us to have one single source of truth while not overwhelming the teams with the added responsibility of manually updating their epics, stories, and/or tasks.
Raghavender Benkal says in a Planview LeanKit review
BSA at a insurance company with 5,001-10,000 employees
We have a monthly release cycle. Before using the LeanKit board, we used to use many other tools, and we always would see the crunch on the day we needed to release. Sometimes, our work would extend into overtime. We have also seen some of the features slip through the cracks in the sense that we would miss releasing them. It was, in a way, a bit chaotic. Once we started using LeanKit, we haven't missed a single feature from deployment. We are also able to better manage the capacity so that we're not over-booking ourselves for work where there is no capacity, and that has really helped. For over a year now, we have not missed any deadline.
It helps us not to over-promise. Basically, the motto we all have is "Under-promise, over-deliver." That's what it helps us do. So, we know what we plan to deliver, and we don't crush ourselves by promising beyond our capacity.
We use LeanKit's board and card hierarchies. We have an initiative board, which is basically a high-level board where any new projects that are coming into the pipeline, or basically into the backlog, will move from one lane into the other. This helps the scrum master in looking at how the projects are moving. We also have trial boards, where the stories, the features, and the tasks are managed. For example, if there are a couple of projects that are impacting a particular feature, then we can link those two projects to this feature so that we know which updates are impacting which projects or initiatives. This way, whoever is managing the projects will know the progress of work as well as the impact on those individual projects. So, it removes the risk of doing something that will impact some other project. These boards help us this way, and it is one of the many examples.
It provides a visual ability to look at the deadlines. When we use a card, we always have a scheduled finish date. As the date is approaching, the color of the date icon changes, so it has a visual way to say that we are nearing the finish date, which makes us take a look at it and check whether we can meet the deadline or not. So, as we are near a deadline, the date icon's color changes to yellow, and once we pass that date, it changes to red. When it is in yellow state, we do a deeper review of the card and see whether we are still okay or not, and most of the time, we are okay with those dates. If not, it helps us to replan and see where we go from there. This is absolutely helpful in project delivery.
The main thing is that we know what's in the current sprint and what we have planned to deliver. We know what those dates are. All the deliverables are in front of our eyes in the form of cards, like a schedule. There are lines, dates, etc. We know who is working on what. We typically have a daily standup meeting in the morning in which we review the cards in the Develop lane. We have multiple processes, and in general, if somebody is working on a feature, we already know what is happening. We do a one-minute review of each card and look at it and say, "Hey. Are we still on target? Is there any issue that is stopping us from working on that feature or functionality?" That's basically what it is. So, we know whether we will make it or not. It basically gives us the flexibility to look at any risk to delivery beforehand, and that way, make adjustments so that we won't miss a delivery.
We use the Card Health feature, and we also use other reporting features on the card. Generally, we do a review on a daily basis where we are with things. We are a small team, and we know what's happening with each card and whether we are going to make it or not. So, we already know what's happening on each card, and typically, only when we are doing our sprint introspection, we go and take a look at the predictability aspects. We sometimes look at the predictability that a particular report is giving during the standup meetings, but usually, we review the Card Health information retrospectively to see whether we can make any improvements in the future so that it is much smoother.
The Card Health feature activity stream affects our project management and delivery, but we have always looked at this after the fact. We usually don't use that on a daily basis. However, we do look at every card every day so we know where it's going. We will get to know if there is any risk in delivering a certain feature. It takes our attention to those cards to say that there is something going on with it, and we need to look at it. It needs a different analysis.
The board analytics helps with the speed and looking at how we are doing. It helps us to see if we can accommodate additional features within the sprint. In case, we have everything on target, we can pull additional cards to work on them, and board analytics helps with this. It also tells us how we are doing and how we are estimating.
LeanKit has reduced our cycle times because as we finish the planned work, we now know if there is more room to do additional work. So, we have the ability to know how we are doing. In this sense, it has easily reduced 50% of cycle time.