Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Many of the same factors used to improve cycle time apply to improve the velocity of agile teams. Velocity and cycle time sometimes get confused and it’s understandable because they are closely related. Few state their relationship better than George Dinwiddie, “Given that Cycle Time is Time per Work, and Velocity is Work per Time, by adjusting for units we see that these are reciprocals of each other. They are related in the same way that wavelength and frequency are in physics.” Like with cycle time, there is no single silver bullet to improve the velocity of agile times except with a holistic view of the software development process.
In Agile, velocity is a measurement of the amount of work that a team can complete in a single sprint. The length of a sprint varies by company or team but is typically 1 to 4 weeks. Work is usually measured in story points or hours. Velocity is an essential metric for evaluating team productivity and planning the work of each sprint. To an extent, it can help predict the delivery of new software features, but only on a very short-term basis. It’s dangerous to use it this way beyond one or two sprints – and besides, there are better metrics for that, like cycle time.
Velocity = Number of Agile Story Points Delivered/Number of Sprints.
Alternatively, you can use a Running Average Velocity, which is typically based on your last 3-4 sprints. Running average tends to more accurately predict velocity, except when you have changes in your team or project. And even though anomalies may skew it, the running average will tend to correct itself over time. On a case by case basis outliers can be dropped from the running average for the sake of consistency. If a large variation repeats, a closer look to determine why is in order.
Work Capacity is the amount of time your team has available during a sprint. The basic equation is:
Agile Capacity = # of Team Members * # of Days in the Sprint * # of Productive Hours per Day
Productive hours factor only the time spent working on a user story. It doesn’t include time for meetings, emails, mentoring or training, etc. The typical baseline starts at 75% of work hours, or 6 hours for every 8 hour day. With 8 team members averaging 6 productive hours per day in a sprint based upon a regular week with 5 work days, you would have a capacity of 240 hours.
Capacity is impacted by holidays, vacation and sick days, changes in team composition, some team members assigned on a part-time basis, etc. Velocity planning considers capacity for defining Load – the number of points assigned to a team to deliver in a sprint.
The burndown chart is a graphical representation of sprint velocity. With it, you can reasonably predict how long it will take to complete the planned user stories with your current sprint. Burndown velocity shows if stories will be completed ahead of or behind schedule.
A Control Chart is another visualization for showing velocity by task. Circles or task plot points higher up on the graph took longer than expected to complete and deserve investigation to find out why. Knowing which tasks are taking longer than expected can help determine whether they are one-time anomalies or are likely to repeat.
Software developers must be productive. The first principle of Agile Development is “Customer satisfaction through early and continuous software delivery.” The third principle qualifies that the software delivered must work. The seventh principle stipulates, “Working software is the primary measure of progress.”
In the scramble to complete a sprint, quality can take a hit that can have a knock-on effect across the entire project. But perfectionism can also cause problems. It’s important that you define what constitutes “Good Enough Code” for your team. If you focus on quality first, you’ll reduce the need for rework – and that’s good for all performance metrics and cycle time.
The more data you collect and the longer you collect it, the more valuable it is, especially when you can combine it with other metrics. Velocity, like most other metrics, is not something that works well for comparing different teams. Each individual on a team has their own skills and experience, the project has its own nuances and complexity, and lots of other variables.
Performance metrics shouldn’t be used to compare or penalize developers. It generally follows that if a team is sophisticated enough to be tracking performance that they also have an improvement process. The improvement process, if followed, will practically guarantee continuous improvement. Practice makes perfect, but by the time you realize perfection, your standards for it will have changed, i.e. technical debt.
Of course, if you don’t have a development program for your developers, it’d be a good idea to get cracking and set one up. At the same time, if you aren’t using any performance analytics, we hope you’ll give Gitential a try (free trial, no credit card needed!)
As with cycle time, improving the velocity of agile teams requires a holistic approach. Everything’s connected and in such an intricate way that wherever you choose to start will lead you from one point to the next. However, all of the data that you are accumulating with cycle times, sprint burndown charts, and performance metrics can help you identify where to concentrate efforts for the greatest or fastest impact.
Project Requirements: To a large extent, project requirements should define your ideal team composition. This relates to their skills and experience with programming languages, software components, complexity, etc. If your team doesn’t have the skills required for the project, they’ll either need to learn it on the fly or bring in another developer with the skills.
Estimation methodology: How you estimate story points can influence the effectiveness of your planning. There are several estimation techniques like planning poker, T-shirt sizes, the bucket system, and dot voting, among others. For purposes of consistency, it’s best to maintain the same technique across all projects for your team. If that’s not possible, realize that a change in your estimation techniques will have an impact on scheduling.
Changes in scope: The estimation process itself evaluates the work associated with each story point. Avoid changes to the scope of the story point once it has been assigned. The extra work it involves may not be finished by the end of the sprint.
Team Size: As Guy Gershoni discusses, software development team should have 5-8 members. In part, it depends upon the team leader’s management ability. But, the formula: N (N-1) / 2 defines the number of team interactions. With a team of five there are 10 possible interactions; a team of seven expands it to 21; adding two more pushes it to 36 possible interactions. This all weighs in terms of planning the work of each member, meetings, reports, emails, etc. Functionally, the larger your team – the slower it is likely to be.
Team Composition: The more (and longer) you use software development analytics, the better you’ll be able to make data-driven decisions to optimize your team for each project. The Tiobe Index tracks a short list of over 100 software languages, but even teams that regularly only use 4-6 may not have a firm grasp of who knows which language best (or at all). Developers may be reluctant to admit that they don’t know a particular programming language very well.
Cross-Training: Who is on your team is just as important as how many are on it. Each team member isn’t limited to one function. As Guy also discusses, an engineer with experience as a business analyst and QA specialist could fill three roles. Promoting cross-training across your team provides coverage for sick days and emergencies.
Developer optimized-tasks: Break user stories into small, logical pieces suited to the skill of the team member/s tasked to do it. This ties into your “Definition of Done” especially when your team has many junior, but few senior, developers.
Communication and Collaboration: There’s some more “C-words” again! Software development is complex with a lot of moving parts that need to come together. Keeping the Sprint Burndown available to everyone is one way of keeping everyone aligned on progress and what needs to be done. Every meeting is an opportunity for team members to identify barriers and dependencies.
Article updated: June 08, 2022
Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
