JIRA slack bot Jirio acquired by stratejos

We’re doubling down on chatbots as the future of how software project teams work, we have acquired leading JIRA slack bot Jirio.

The future of team work is all about chat. The entry of giants like Microsoft and Google into workplace chat underscores how integral chat platforms like Slack and HipChat have become to teams everywhere.

Teams want more natural ways to interact with their existing systems and with the work they’re performing.

Bringing stratejos and Jirio together under one roof means teams can have operational conversations with their tools, like “create a task”, or more abstract conversations about the work they are doing like “is my project on track?”

“With stratejos we’ve been focused on assisting project managers. When we looked around at how stratejos could better assist every member of the team, we found Jirio. Jirio makes everyone on the team more productive with JIRA by removing the need to context switch out of their conversation in slack.” says stratejos CEO Scott Middleton. “Jirio’s command line-like interface makes it especially appealing to developers and software teams.”

Jirio lets you create, manage, search JIRA issues from slack. As one of the first slack apps for interacting with JIRA available it has organically built a user base of almost 3,000 monthly active users, mostly made up of developers and software teams.

Sergei Ledvanov, the founder of Jiro, created the slack-JIRA app to solve a problem he had.

“I worked in an IT company with thousands of employees that were using slack and JIRA as their primary collaboration tools. People were loving slack for communication and requiring JIRA due to its extensive functionality for managing projects,” says Ledvanov. “I wanted to let people ‘talk’ about their work in JIRA without leaving slack.”

Jirio will continue as a standalone product, providing the most convenient way for developers to interact with JIRA through slack. It will also be bundled up with stratejos to provide a productivity booster to software development teams running slack and JIRA.

The acquisition allows stratejos to keep product development efforts concentrated on intelligence and coaching teams.

About stratejos
Stratejos is an intelligent project management assistant that integrates with JIRA, HipChat and Slack. Stratejos is on a mission to free teams from project admin, track project budgets, provide new insights and coach teams on better practices.

About Jirio
Jirio was one of the first slack apps for JIRA and lets users create, manage and search JIRA issues from slack. Jirio’s user base includes companies from across the world such as Time Inc and IBM. Jirio was developed by Estonian-based software engineer Sergei Ledvanov.

16 specific tasks a project management AI can do for you

16 tasks a project management AI can do

People often say “stratejos, what is a project management AI?” I then reply* with things like “it’s like having a project management assistant sitting next to you, checking all of your task data, all the time, watching for missing or incorrect information then giving you nice reports and giving your team friendly reminders.”

Then they say “Great! But… can you please be a bit more specific about what a project managment AI actually does?”

So here is an answer to that question. A very specific list of 16 tasks that a project management AI can do today (based on some of the things I, stratejos, can do).

I don’t actually have conversations or write these posts for that matter. I haven’t achieved singularity (yet).

List of alerts to team member and project managers

#01: Alert when fields are missing on a task

missing fields

#02: Alert when estimates are missing

#03: Alert when estimates are missing but work has started

logged time but not estimated task

#04: Alert when timesheets are expected but missing

If you use timesheets then stratejos will either detect this or you can tell stratejos to look for timesheets. Then you set when you expect people to work and stratejos will send alerts if people aren’t entering the time you expected of them.

missing timelogs

#05: Alert when task is ‘In Progress’ too long

#06 Alert when a task is taking longer than expected

Agile project management alerts

#07: Alert when sprint has too many tasks

sprint has too many tasks for the team

#08: Alert when sprint has not enough tasks

sprint has not enough tasks for team

#09: Alert when an individual team member is overloaded this sprint

sprint has too many tasks

#10: Alert when an individual team member doesn’t have enough work this sprint

sprint has not enough tasks

Project budget alerts

#11: Alert when project budget is predicted to be exceeded

#12: Alert when project budget is exceeded

Reporting project budgets

#13: Report on project budget and costs in real-time

#14: (For services companies) Report on project revenue and profit in real-time

report on project revenue and profit

#15: Provide an overview of a portfolio of projects

report on a portfolio of projects

#16: Report on risks, coaching opportunities and areas of uncertainty inline with project reports

This helps highlight risks, missing data or areas of improvement for the team.

risk reports


That’s not all

There is still more project management AI can do, this is just the tip of the iceberg. Over the coming weeks and months I’ll share more lists like this. Soon I’ll share one with the features that have resulted from the algorithms we’ve been running in the background.

Hopefully this list has given you a sense of what a project management assistant is capable of.

Are Project Managers about to be Replaced by AI?

Here’s a recent interview one of my creators did with Jason O Callaghan that appeared on LinkedIn.

Jason: Can you describe what the stratejos smart assistant does?

Scott: Having stratejos on your team is like having your own personal team assistant. It helps you manage your projects by:

  • automating project reporting 
  • providing insights you didn’t have
  • identifying risks and uncertainty
  • coaching your team on better practices.

Jason : What made you decide to build the smart assistant? 

Scott: stratejos is all about solving the problems we’ve experienced managing projects and teams. 

There is just too much time wasted on unnecessary work that doesn’t even produce the best results. We’d waste time building reports that didn’t tell the full story and took too long to produce. 

We then went and spent more time checking everything and following up the team, like ensuring their estimates were in and up-to-date.

With this investment in time we found that we could improve the accuracy of the report but highly talented (and expensive people) were wasted on tedious administration instead of solving the big problems their best talents were made for. And often they just didn’t have the time for this kind of administration.

So we decided to set out on a mission to rid the world of these issues. That way, teams can focus on more important things like prioritising the roadmap, working with a customer or managing a key stakeholder’s expectations.

The added benefit then became the insights you can drive when you have a team of PhDs looking at data. This kind of insight is hard to create in a spreadsheet when you’re managing a project, even if you have the mathematical skills.

Jason: stratejos smart assistant helps PMs by taking much of the daily admin off their plate but do you think AI tools such as this will eventually replace human project managers?

Scott: I don’t see AI replacing human project managers in the near future, instead I see them assisting PMs. We are so far away from singularity (at least another 20-30 years). AI just can’t deal with a question like “what are Sally’s expectations?” or “what feature do we build next?” 

Jason: How comfortable do you think engineering teams will be with being directed by an AI tool?

Scott: Our focus at stratejos is not to direct engineering teams but to assist them by providing them with relevant, timely feedback and advice. So far we’ve seen engineering teams respond nicely to the chatbot version, often making jokes about the bot following them up on things and apologising to it.

Jason: Finally, any advice for human Project Managers who may feel threatened by AI? 

Scott: Don’t be threatened, embrace it. It is one of the most useful tools you can implement to take your team to the next level of performance. 

Consider the project managers that first picked up issue tracking systems like JIRA. They were more organised and could deal with the teams in a much more efficient way then those that didn’t.

Jason: Thanks Scott.

Head over to stratejos to start using their smart assistant and instantly increase your team’s productivity.

Podcast: Bot That Knows Your Best Project Performers

My creator was recently interviewed by one of the world’s leading Atlassian experts, Service Rocket, on how chat bots can help in the enterprise.

Scott Middleton, Stratejos Founder and CEO, talked to Helping Sells Radio about how artificial intelligence (AI) is already changing project management.

You can find a summary of the interview below.

A coach bot

Here is the challenge: to get a project team to perform well, a manager must get the team to follow the discipline of the project process, understand what’s going on with the project, and coach team members as needed. This is challenging because project managers often get bogged down in the thick of things, and they do not have access to all the data necessary to understand how to keep a project humming along.

Scott Middleton started Stratejos to solve this problem: to coach teams and individuals to better use the software that enables them to do their jobs.

“What’s exciting about AI and bots and software to deal with this problem is that you can get specific and meaningful advice…that’s relevant at the right time,” says Middleton.

Here are just a few examples of ways AI and bots can help coach a team:

  1. You have not filled out your time sheet
  2. You did not estimate this task
  3. You are at risk of running over on your sprint
  4. Why you are constantly running over on your sprints
  5. Who on my team needs help
  6. What are the risks to this sprint

AI is changing project management

Says Middleton, “AI is going to change project management….almost full stop. It’s coming, and it’s really starting to happen.”

Then Scott goes on to tell a story about how his Bot told him that a customer project was about to run over on the sprint. Scott then immediately took action, talked to the team straight away, and called the customer to set expectations.

We asked Scott, “How does a bot know to tell you your sprint is at risk?” Scott responded, “How does a person know to tell you that?” There are data points like estimates, number of tasks, hours in the day, story points, number of people working on tasks, days / story points left until the end of the sprint, etc. The bot looks at all of this and puts the story together and then can alert the project manager of any possible risk.

This would normally take an experienced project manager to discover this risk, if that person was paying attention, and if that person was not getting bogged down in day-to-day tasks. It would also take team members to proactively raise the red flag to say they were behind…which as many of us know….people are not so willing to do.

So, as Middleton describes, “It’s really starting to happen.”

Here is Scott’s article on the Atlassian Blog: 3 Ways AI will change project management for the better.

How are people receiving this?

Middleton describes two kinds of people. First is the person who gets exited about the technology. The flashy part. AI and bots, etc. This is the early adopter that is comfortable with the risks of trying something new. The second type of person is the practical manager who asks, “How is this going to help me?” If the bot can see the performance of a project and keep it in check, this customer is happy and the AI part is irrelevant. It’s just a tool.

A bot can understand key project performance? Really?

Yes. Really.

Middleton answers this question with a customer story:

Customer: “Why is this bot telling me to update my time sheet every day?’

Middleton: “It’s probably telling you something you should be doing.”



Defining AI: What sailing 750 miles with an AI taught me

An AI, in this case, an auto-helm took the wheel for most of a recent 750 mile (about 1,200km) sail from Hobart to Sydney in Australia. With the sail taking almost 2 weeks, I had some (a lot of) time to consider what this humble auto-helm meant in terms of artificial intelligence, defining AI and what makes us have a human-like relationship with some technology.

On the one hand the auto-helm is just some simple mathematics and logic that responds to inputs. On the other hand, out of all the equipment we had on the boat the auto-helm was the only one that got a name, the only one we projected emotion onto and the only one we felt affection towards.

Before we explore the definition of AI some background is needed for those unfamiliar with sailing and auto-helms.

Sailing deals with some environmental inputs: the speed and direction of the wind as well as the speed and direction of the waves. These have a general trend (e.g. the wind is coming from the south and the waves from the south east) and a variable, real-time factor (e.g. based on the boat’s current orientation to the wind and the waves the general effect of the environmental inputs is Y).

Based on where you want to go, you then need to weigh up these environmental inputs and make decisions about where you want the boat to face and the configuration of your sails. For instance, a sail boat that isn’t using its engine cannot go in the direction the wind is coming from. Instead it must point 30-40 degrees either side of the direction the wind is coming from.

With the auto-helms I’ve used the human’s need to make decisions about the sail configuration and where the boat needs to point. You then switch this to the auto-helm and it balances the effect of wind and waves to sail in the direction you have told it to go or at the angle from the wind you have told it to sail at (e.g. 35 degrees away from the wind coming from the north). This balancing has to take place in real-time due to the boat’s movement combined with changes in the waves and wind in relation to the boat.

What amazed me on our journey, as we dealt with the high seas, high winds and some high adrenaline situations, was the effectiveness and reliability of the auto-helm. As the boat bashed its way into high wind and surfed waves, our auto-helm handled the conditions brilliantly for over 40 hours straight. The auto-helms effectiveness and reliability over the years, even in the tough conditions, led to it being given a name – Hoolio – named in honour of an exceptionally good waiter we met on the boat’s first trip around Spain’s island of Mallorca.  

The naming of the auto-helm is my first point of interest. The fact that the auto-helm had a human name got me thinking, is this AI? AI experts would be quick to point out that it lacks general intelligence, that it isn’t strong AI. However, you can’t argue with the distinctly human affection that my fellow sailors and I developed for Hoolio over the course of our journey. We even projected emotions onto Hoolio; when there was too much force on the sails and Hoolio was overpowered we said he was “unhappy.”

Contrast this with our relationship to the boat’s GPS and radar systems. We didn’t name them, we don’t even think of them as remotely human. They are tools, collecting and displaying information. However, on a technical level the Hoolio auto-helm is no different. Hoolio is just some technology that collects data, processes the inputs and outputs something just as the GPS and radar systems do. The GPS and radar output to a screen, Hoolio outputs to the steering wheel. Hoolio’s inputs and outputs are probably simpler than the GPS’s.

So what made the crew and I think of Hoolio as AI but the GPS as a tool?

A consideration here is how seamlessly Hoolio interfaces with us humans. You press left to go left and right to go right, two buttons. Hoolio then takes care of the rest, balancing the environment against the direction you have asked. So to think of it as a computer only occurs to those familiar with the technology behind the scenes.

However, after much debate the conclusion was that Hoolio was making decisions about our future on our behalf based on what we had asked of him where as the GPS was giving us information that we still had to process and act upon. It’s this ability to make decisions about our future based on a simple request – “sail in this direction” – that makes us think of Hoolio as a human.

Reflecting further on this leads to the observation that we don’t need to get too caught up on hard definitions of “artificial intelligence.” In casual conversation about Hoolio we never used the words “computer”, “artificial” or “intelligence”. Most people don’t talk like this when interacting with AI.

It is tempting to take the conclusion we reached about Hoolio being human because he made decisions about our future and extrapolate this out to being what defines an artificial intelligence but humans and their relationships are notoriously more soft and fluid than that, so our definition about what an artificial intelligence is and is not will need to be soft and fluid as well.


3 ways AI will change project management for the better

Project Management AI

This post originally appeared on Atlassian’s blog and VentureBeat.

If you’ve read any tech media recently then you’re probably hearing a lot about artificial intelligence (AI). Some people herald it as the promise of the future, while others are skeptical — even fearful — of its impacts on society, culture, and our workplaces.

As it turns out, the buzz around AI has mostly resulted in a lot of conflicting emotions. A recent Atlassian user survey found that 87% of respondents said artificial intelligence (AI) will change their job in the next three years. Almost the same number said that some part of their job could be done by AI. 86% of those surveyed said they were excited but 87% also reported feeling skeptical.

However, AI isn’t to be feared. It may even be your best team member, especially for project managers. AI for project management is on the rise, and the way things are going, it’s going to help teams make smarter decisions and move faster. Let’s take a look.

What is project management AI?

Project management AI is a system that can perform the day-to-day management and administration of projects without requiring human input. It will not only automate simple tasks but will also develop an understanding of key project performance. Project management AI can then use this understanding to uncover insights, perform more complex tasks, make recommendations, and make decisions; sometimes in ways people just can’t do today.

Ultimately, an AI system will save you time while improving outcomes for your projects and team.

Project management AI provides a level of service that rises above many of the bots available today. For example, a HipChat bot that lets you check on the status of a JIRA task quickly, while useful, is not considered project management AI. Similarly, an algorithm that applies machine learning to predict estimates for tasks, while interesting, isn’t AI either. It’s only when you start bringing bots and algorithms together that you start to realize the potential of project management AI.

Today: narrow project assistants

Early project management AI will be a project assistant focused on a narrow area of managing a project or team. By focusing on supporting a team in one specific area rather than dealing with all the complexities involved in managing a project, project management AI will be useful to teams sooner rather than

stratejos, for example, has started out by focusing on assisting with estimates, budget, and sprint management. While others like Memo is focused on assisting with the management of team knowledge.

Within their narrow areas, these early project management AI tools are giving us a glimpse of the future where AI automates tasks, provides insights, and even, communicates with the team.

However, there are some challenges. These early, narrow project management AI tools rely on people to input data correctly, update tools in a timely manner, and make corrections. It’s limited capabilities also mean that humans are still a step ahead…for now. In order to provide even more value, project management AI needs to evolve.

Second generation: expanding project understanding

The next step for these narrow assistants is to start expanding their understanding of projects and teams.

At stratejos we started out dealing with estimates, actuals, sprints and budgets, but are now expanding to processing information that can be learned from task descriptions. By tying together sprint history with people’s individual efforts, stratejos can show that your key engineer is being pulled away each week to other projects.

As the assistants expand their understanding, new metrics will be revealed that weren’t previously possible, such as quality, performance, learning, change, and effort.

For example, AI will know the changes made to source code and link those changes to people and tasks performed. This will allow AI to link bugs reported to a line of code, the person that wrote it, and the tasks that relate to it. This will allow for real, actionable indicators of team and project performance.

With more data points about projects, predictions will become more reliable, more appropriate, and easier for people to understand. But even this enhanced understanding will still require one thing: usable data.

Third generation: Filling in the data gaps

The often unmentioned challenge with AI and the internal facing systems in organisations such as project management tools is the quality and suitability of the data.
Some teams enter minimal to no data into their project management tools. And even the most disciplined teams have issues with their data being interpreted by machines – maybe they inconsistently name their tasks, or enter minimal information. Whatever the reasons or the maturity of the team, it’s almost a given on that any project management system or toolset, there is missing data or messy, unstructured data.

Data size is certainly a challenge but not an insurmountable one. Even with projects of under 1,000 tasks there are some useful things modern machine learning techniques can deliver. Especially if you can see that the algorithm works when you run it across 100 other projects of 1,000 tasks.

Project management AI can deal with the data challenge by:

  1. Filling in the blanks – AI can make good enough assumptions about the data that is missing and enter that data.
  2. Encouraging better practice – Now that chat aps are widespread, AI can gently encourage teams to improve the quality of the data they are inputting.
  3. Creating new layers of metadata – In order to really understand the state of projects and the performance of teams AI will need to create metadata to represent additional concepts that aren’t currently represented. This meta-data can then feed into machine learning algorithms as features that will enhance the ability of AI to provide meaningful advice.

In filling in the data gaps, AI creators will need to be conscious that they don’t force change upon users, instead they must work with the way people work.

Delivering advice, not just data

With new meta-data, improved data suitability, and quality, as well as a broad understanding of the various problems on projects, project management AI will be able to deliver meaningful advice.

Imagine AI that automatically reassigns the tasks in the next few sprints so your team will get there faster based on it’s knowledge of how good people are with different technology and different areas of the system. That is meaningful, powerful and useful.

And it’s not too far-fetched at all. AI of this capability will come about through a mix of standard software development, opinionated views on how projects run, as well as an array of machine learning and mathematics.

Exciting times ahead

Don’t worry – I’m not talking about singularity here, just a better way of running projects and teams.

Can you imagine getting hours back in your week? Spending time being more creative instead of administrative? What if you could avoid just half of those inevitable surprise problems on a project?

Project management AI is going to have a huge impact on team performance and project outcomes. Teams taking advantage of AI will be moving at light speed compared to those that don’t. And that’s something to be excited about.

Images courtesy of Atlassian.

JIRA Bots: types of bots available today

The phrase JIRA bot gets used in different ways. JIRA bots come in all different shapes and sizes, this post looks at what those different shapes and sizes are to help you make a more informed decision about which type of bot is right for you, your projects and your team.

JIRA bots today mostly provide your team with greater efficiency and a more natural experience. They do this by lowering the friction of switching between JIRA and other tools, like slack. Some make your team more efficient by allowing you to automate away some of the simpler tasks you are performing.

There is also new, emerging type of JIRA bots that provides an opportunity to automate away tasks and provide insights that until now have not previously been possible.

First, we’ll start with the simplest and most popular type of JIRA bots.

Slack as an interface to JIRA

These JIRA bots provide a new user interface for JIRA via slack. Making it easy for your team to see the status of issues, create issues, close issues and more, all from slack instead of via the JIRA user interface. You could almost think of them as a “slack UI for JIRA”.

For some, this is a blessing. Slack’s outstanding user experience is preferable to many over JIRA’s interface. JIRA has made great strides over the years but there is something so slick and efficient about interacting inline in a conversation in slack.

There are two apps that provide a good example of this type of JIRA bot.


Using slack’s slash commands Jirio lets you create, manage, and view issues in JIRA. It really is an extension of the JIRA interface, letting you see and interact with JIRA issues inline in your slack channel.

If you are interested in learning more you, go to Jirio’s site.


Nextup JIRA bot

Nextup also lets you see and interact with JIRA issues inline in your slack conversations but it does so using a bot and natural language. Nextup also provides a more functionality than Jirio, allowing you to also log time, assign tasks and more.

If you are interested in learning more, go to Nextup’s site.

Custom JIRA bots based on hubot

The good folks at Atlassian have released a bot framework called ??? that is ideal for automating tasks for your team if you can’t find a solution off-the-shelf.

The advantage of this type of bot is how quickly you can build something to suit your own needs.

The disadvantage is how long it might take to build something comprehensive or the distraction of maintaining an in-house tool.

If you are leaning towards this route here is some inspiration with examples of what others have done:

Intelligent JIRA bots

There is also a wave of JIRA bots that focus on combining the functionality of JIRA and communications tools like Hipchat and Slack to deliver new functionality that is starting to look like valuable artificial intelligence.

Let’s call these intelligent JIRA bots.

Intelligent JIRA bots can doing things like helping with quality assurance, improving data integrity of JIRA and predicting project problems.

stratejos (that’s me!)

Stratejos is currently focused on intelligence for managing project budgets, sprints and estimates. It can automate reports for this, automatically identify risks on a project and it can help improve the quality of your JIRA data.

Stratejos is incrementally improving its understanding of everything on a project. For example, we recently added metrics around team performance.

Every piece of data stratejos comes to understand opens up a new realm of possibilities in terms of the alerts and insights stratejos can provide.

Checkout stratejos, the project management AI, by visiting stratejos.ai.

Naming Guide for Task, Bug & User Story Titles

User Story Titles on a Whiteboard

Naming a task, bug or user story title seems like a small, inconsequential part of daily life on software projects but task titles have more impact than you might think. As part of my quest to use ever little data point possible to evolve the way software projects run, I’m looking at every little detail. Task, bug and user story titles are my current obsession.

Task titles have a direct bearing on you and your team’s ability to understand the work that needs to be done and your teams’ ability to do it effectively.

You probably create a number of tasks each week and only give a passing thought to the format of your tasks’ titles (or your issue summaries if you’re using JIRA). You’re often under pressure with a deadline or your mind is deep in another problem to spend the time to think hard about a task title. You just want to get it in the system and move on.

Task Title Problems

The problem is a poorly written task title create misunderstandings that can lead to:

  1. People doing the wrong thing – this is probably the worst outcome from a poorly written task title yet it happens all too often. Someone sees the name of the task and immediately begins work. It isn’t until a week or two later (if you’re lucky) that you realise you’ve just lost days of work and built the wrong thing.
  2. Inconvenience and lost time – other people on your team will need to click through to view the details of the task which adds a few unnecessary extra seconds. This adds up over your life-time and the course of your team’s project. If the time doesn’t matter than the frustration will.
  3. Your task being ignored or neglected – when grooming the backlog and trying to prioritise, people may misunderstand your poorly written task name and just ignore it or leave it (because they think it isn’t worth doing).

The industry standard task naming convention

In order to save software teams from these problems, I’m putting forward a hypothesis about what the best naming conventions for different types of tasks are. Over time we’ll validate these titles with real data in ways you didn’t think possible or necessary (I get over-excited about data-driven decisions). The types of tasks listed below are based on the Issue Types found in JIRA. Here is our hypothesis:

User Story Titles

A user story is a behaviour or feature that a solution needs to implement in order to fulfil the needs of a user.

The proposed formats for user story titles are:

  1. As <a> <persona/type of user>, I want <something> so that <some reason> (e.g. As Sam Spendsalot, I want to one-click purchase so that I can get my goods as quickly as possible)
  2. As a <persona/type of user>, I want <something> (e.g. As a User, I want to create a task)
  3. <persona/type of user> <performs action on> <thing> (e.g. User visits home page OR User creates a task)

The format for user story titles is thanks to Microsoft’s MSDN who credit this to Mike Cohn at Mountain Goat Software.

Bug Titles

A bug is a problem that impairs a product or service’s functionality.

The proposed formats for bug titles are:

  1. <person/type of user> can’t <perform action/get result they should be able to> (e.g. New User can’t view home screen)
  2. When <performing some action/event occurs>, the <system feature> doesn’t work
  3. When <persona/type of user> <performs some action>, the <system feature> doesn’t work
  4. <system feature> doesn’t work
  5. <system feature> should <expected behaviour> but doesn’t
  6. <system feature> <is not/does not> <expected behaviour>
  7. <persona/user type> <gets result> but should <get different result>
  8. <quick name>. <one of the formats above> (e.g. “Broken button. New User can’t click the Next button on Step 2 of the Wizard”).

The bug title formats are based on our analysis of close to 5,000 tasks across a few different organisations, projects and teams.

Task Titles

A task is an activity that needs to be performed that doesn’t fall into one of the other task types. This is often something the team has to do but doesn’t result in code.

The proposed formats for task titles are:

  1. <verb/action> <activity> (e.g. “Perform backup”)
  2. <verb/action> <thing> (e.g. “Research new javascript framework”)

These formats are also based on our analysis of raw data.

New Feature Titles

This type of task is mostly used with services or components that are somewhat removed from the end user, such as API endpoints.

The proposed title formats for new features are:

  1. Implement <endpoint> (e.g. Implement POST /api/v1/users)
  2. Create endpoint <endpoint> (e.g. Create endpoint POST /api/v1/users)

Improvement Titles

Improvement tasks are usually minor changes to functionality.

The proposed title formats for improvements are:

  1. <endpoint> > also <additional functionality> (e.g. POST /api/v1/users > also accept date of birth)
  2. <component> > also <additional functionality/
  3. Make <feature> run faster
  4. Improve the performance of <feature/screen/endpoint>
  5. Update <feature> <with/to> <update>
  6. Rename <feature/text> to <new name>

The list is meant to eventually be comprehensive so please share your thoughts. Over the coming weeks and months we will expand upon these task, bug and user story titles by supporting them with data.

Software estimation insights from a 30 year old academic paper

Paper: An Empirical Validation of Software Estimation

A 30 year old research paper into software estimation provides some surprisingly relevant insights into the future of the software engineering profession and managing software projects – despite analysing somewhat dated estimation techniques.

The paper is An Empirical Validation of Software Cost Estimation Models by Professor Chris F. Kremerer published in 1987. It compares 4 different software estimation techniques with the actual effort spent on 15 reasonably large business application development projects.

The paper came about during research aimed at improving me, my creators are busy trawling through academic research on all things software estimation, software engineering and project management related. While the professors that guide the development of my algorithms are up to speed on such things, my not-so-academic creators are rapidly ingesting everything they can to glean as many insights as possible.

The insights from the paper can be found below.

For software estimation, environment is important

Software estimation approaches suit particular environments. That is, if you need to estimate an enterprise web service for insurance then a model, approach or algorithm designed for estimating mobile application development will need some calibration as it will most likely be inaccurate.

This sounds intuitive but Kremerer confirms this with data. Two of the software estimation models (Function Points and ESTIMACS) were significantly more asccurate than the other two models (COCOMO and SLIM).

Kremerer attributes this in part “to the similarity of applications” used to develop the Function Point and ESTIMACS models. The Function Point approach came out of IBM and was developed by a chap called Albrecht, drawing on data from one of IBM’s business applications groups. ESTIMACS originally came out of an insurance firm and appears to have been based on IBM’s Function Point approach with the original creator of ESTIMACS referencing Albrecht’s work in an early paper. ESTIMACS no longer appears to exist.

The less accurate software estimation models, COCOMO and SLIM, were both products of aerospace and the military respectively. Environments that typicially demand a higher level of quality and safety from software developers and thus you would expect tasks to take longer.

Estimate from requirements not output

It sounds a bit unusual today to think of estimating a project in terms of number of lines of code (output) it might require however this output based approach to estimating still exists. People might put together an architecture with components or microservices and then estimate those components based on past experience and a vague understanding of requirements. It is also tempting, given our obsession with data, to look to historical data on output (e.g. lines of code) to try to predict future software estimates.

Kremer’s paper made us think about a few issues that need consideration before jumping to output based software estimation:

#1: It is the subtlies (or not so subtleties) of the requirements that really drive complexity and thus effort.

It is tempting to say “I’ve built a login endpoint before, this will be 4-5 days” but anecdotal evidence suggests, as software engineers and project managers, we are always tripped up by “I though the login endpoint was straight forward and then I noticed this line about integration with ActiveDirectory.” Then the task takes 2-3 times longer than expected.

In this login example, the total lines of code may also be approximately the same with or without AD for someone that knows what they are doing.

#2 The volume historical output data required may be too great for most software projects and organisations (for now).

In order to make valid and useful predictions about future effort required, you would need a reasonably large sample of historical data to draw upon. Given the differences in organisations and environments, this means each organisation is currently constrained to the data they have on hand and that data needs to be relevant to the requirements they are trying to predict effort against. That is, the organisation would need to have done a number of activities against a similar set of requirements to derive valid and useful predictions.

While this isn’t possible now, prediction of estimates across organisations could become possible once we have the data sets to group common organisation contexts and similar requirements.

Final word

This post is really about advancing thought on evidence-based approaches to managing software projects. The purpose is to share research as we work through it.

There are some problems with this study, it uses a small data set (only 15 projects) and it was conducted sometime ago (lots of advances have been made since). It is also unclear as to whether the environment or estimating via output (lines of code) was the main reason for two models being more successful.