Elements of the Software Development Process

In the world of software development, whether you are creating a new product, or creating new features to add onto an existing application, the process may seem like a black box, opaque and mysterious.

In this new category of posts, we’d like to break down different elements of the software development process and show a little bit of the details that go into this process.

What is the Story Point

Let’s say you are an IT Project Manager in charge of a small team of developers.  You get assignments from other teams, and you need to plan, scope and then communicate timelines, when you think you will be done with those assignments.  Assignments can range from ‘make this icon blue’ to ‘integrate this product with our learning management system.’

Many team leaders will communicate in terms of days and just say, ‘I think it will take X days’ and report that back, but then things happen, emergencies happen, timelines change, priorities shift.  And X days become twice as many days, or more… so in the place of a set amount of time, many Agile teams have elected to work with something called the Story Point.

Unit of work

The Story Point is a relative unit of work, compared to hours or days which are precise and universal.  We use the definition relative here because all teams, their abilities, and the tasks assigned to them are indeed relative.  When previously unknown roadblocks or issues appear, predictions using time can be inflexible, whereas using a relative estimate allows you to compare this to other tasks that only the team has done, and you can add in extra point or points for things like complexity, risk, and any other unknowns.

Origins:  From Extreme to Agile

Story Points were developed originally as part of the Extreme Programming movement, but has since been added to most Agile product development frameworks today.  They are very useful indicators of relative difficulty – a story point score of four is considered twice as hard as a story point score of two.  However, this can vary between teams. As this encapsulates a task’s complexity, amount and uncertainty, this number can mean quite a lot to your team of developers.

Data Driven with Team Velocity, Yesterday’s Weather

Over time as your development team catalogs and reports on Story Points for each 2-week sprint, they can look back and review their overall Velocity – that is, their relative number of Story Points completed.  This is sometimes called Yesterday’s Weather, where a team should only plan to do as much in the future iteration as they got done in the previous iteration.  Not only does this open the door to learning more about your own team, but this also allows for more fine-grained planning and scoping of work, as teams can then say with more accuracy when a ticket of a certain scope can be fit within a sprint, or even a series of sprints.

The concepts of Team Velocity and Yesterday’s Weather allows you to become more data-driven over time in your approach to communicating timelines and determining when a task is doable or unrealistic, and whether or not it requires additional manpower to complete.

Additional reading

Further reading can be found here:
https://martinfowler.com/bliki/YesterdaysWeather.html from Martin Fowler, at Thoughtworks
https://ronjeffries.com/articles/019-01ff/story-points/Index.html from Ron Jeffries, the inventor of Story Points

Contact us

If you’d like to find out more about our project management experience with Software Engineering and how an offshore/nearshore team can work for you, drop us a line at info@thehillsidegroup.com.