Buto uses an ‘Agile’ development methodology, which is a universally accepted best practice method for developing software that’s quick, cost efficient and, most importantly, allows development to twist and turn with clients’ changing requirements. In other words, it helps us to be Agile!
Agile works by looking at a project in ‘sprints’. A Buto sprint is a two-week period of time. During this period an agreed set of functionality will be planned or prioritised and marked for development. At the end of the sprint the code is assessed, signed off and deployed, meaning Buto clients can start to use it straight away. There are three stages for a feature to be developed:
1) Icebox – The icebox is where ALL features, Bugs and Chores (or Stories -see later) are documented. No matter how big or small, they all live in here. These stories can come from within the team, from clients, from research or anywhere.
2) Backlog – When a story is put into the backlog it is then planned in to be developed. The backlog is a prioritised list of features. The developers simply take the top item from the list, develop it and move to the next item.
3) Current – When developers take an item from the backlog they move it to the ‘current’ stage to announce they are working on it. They literally hit a start button, and when complete they hit Finish. The item is then shown as ready to be accepted (or rejected) and delivered.
At Buto we use a SaaS toll called Pivotal Tracker which lets us choose four different types of story: Features, Chores, Bugs, and Releases.
Features are stories that provide verifiable business value to the team’s customer. Examples of features include “add a ‘special instructions’ field to the checkout page”, “purchase history should load in half a second”, and “add a new method addToInventory to the public API”. Features are worth points and therefore must be estimated.
Chores are stories that are necessary, but provide no direct, obvious value to the customer. Examples include “sign up for access to geocoding service” and “Find out why the detailed test suite takes so long”. Chores can represent “code debt”, and/or points of dependency on other teams.
Bugs represent unintended behaviour that can be related to features, for example “login box is wrong colour”, and “price should be non-negative”.
Releases are milestone markers, and allow your team to track progress towards concrete goals, for example stakeholder or investor demos, software launches, etc. It’s possible to specify target dates for releases.
This topic is important because it’s an insight into how we work at Buto and is effectively our Roadmap. As described above, we use terminology which is customer focused and you can see from the screen shot that features are key to what we do with our platform.
As we are a relatively small UK based company in this space compared to some of the US giants (Brightcove, Ooyala, etc), we can react more quickly to our clients’ needs. When a story is added into the system is has the client’s name tagged with it, so we always know who it came from. If there is a deadline for a story, information is added also. A feature request that comes in from a client is assessed and documented accordingly. If it is deemed useful to the platform as a whole (90% of requests are) then it benefits all clients, if it’s very bespoke, then it is separated from the platform development. Often when a client asks for a feature, it’s already in the system and planned in for development!
There are no comments for this post
Use the form below to leave a comment on this post, all fields are required (except website).