Breaking it down

6 years ago

Peter TrimmPost by Peter Trimm (Product Manager). Peter is a recent member of our team, coming to us with over 20 years’ experience working with financial and business management systems, from implementing large scale ERP solutions through to product managing mass market online SaaS based CRM.  His background as a Management Accountant and passion for well designed, easy to use software services, meant he was a natural fit for Sage One.



Here at Sage One, we’ve adopted a method for software development which allows for the commercial and marketing people to work closely with the technical team on a daily basis.

We believe that by breaking down departmental barriers and setting daily and weekly targets for across the teams, it not only brings people together but also facilitates changing priorities and identifies problems sooner rather than later. Our goal is to provide the best software we can, so if the people who work closely with customers and research the market are also part of the development process, then we are more likely to get it right!

You’ve heard the expression ‘only bite off what you can chew’, well this is our approach to work planning. As a Product Manager, I have to understand the big picture in terms of the overall product roadmap; however I need to be able to break all of this down into small, well defined deliverables on which the team can focus and achieve. Together with the development team I can therefore define work phases with start and end dates, scope and set key deliverables. These phases are called ‘Sprints’ and are generally 2 weeks in length. The sprints will have a theme and it is against which we can plan and assign individual specified software features – which are called ‘stories’.

Balancing priorities





Since the granularity of planning is very small, we’re able to manage priorities on a daily basis, and add and remove stories at will. Each sprint kicks off with a planning session in which we set out the theme and product vision and the analysts and development team discuss each story and estimate and assign the work. During the sprint we have a daily meeting, where we can see how we are getting on and identify how we can help each other with problems, and occasionally I get a glimpse of the software! … It is at the end of the two week period where I get a proper view of what has been achieved and review any planning issues.

Having worked in other software houses, where a more traditional method of software development is adopted, I can really see the benefits of working this way, ‘flexible and agile’. I am able to see progress on a daily basis and we can react to changes very fast. Gone a the days that I produce a specification, throw it over the wall to the engineers, duck! … and then wait 3 months and then see what comes out the other side!

The sprint process isn’t unique to software development; our commercial marketing team have now adopted a similar process. What tools do you use to keep on track of planning and delivery within your business? How do you manage your workload?