Energetic. Responsive. Trying Harder. 2014, Here We Come!
Energetic, responsive, trying harder – those were some of the best compliments we received from our customers. As one of them, who switched from a competing product to us, said, “It looks like you guys are always trying harder and better than the rest of them.” Absolutely! The past 12 months have been truly exciting. 2013 was the year in which organizations ranging from boutique consulting companies to global automotive giants, high-security government agencies to Fortune 500 global brands trusted us and our products with their technology.
December 31, 2013
There is a lot of attention given to Lean/ Agile product development teams around the work done and the (Lean/ Agile) processes adopted in by the Dev team once a set of features (backlog items) have been identified for a set of sprints (scrums) and/ or Releases. However, how do those features get to the team, nicely bunched up in Releases and Sprints? There is a lot of upstream effort by Product Management that goes in ‘herding the cats’ – defining and maintaining the Product Roadmap with input from myriad and often conflicting sources abstracting features and requirements at the right level, getting stakeholders to agree on their priority…
That was the question posed in a recent discussion. The question further provides the following details – “I work within an agile team. We have a released product and we are still working towards a future release. Every sprint we receive anywhere from 0 to 5 tickets to fix bugs in the released product. Our team is composed of software engineers (to handle new development) and maintenance software engineers ( to handle tickets). My question is how do you account for the maintenance hours during sprint planning. Currently we have a story called maintenance buffer where we allocate some hours to solve tickets.
