Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery
17
JUL
Are bugs stories?
17 JUL 2012 | Posted in prioritisation, story | Author John Wright |
1 Comment
MailTo answer that you need to define a bug. A bug is something that doesn't provide the desired capability within the system provided.
Now we could get hung up on the difference between a bug and a change, but that distinction is only important for managing the commercial contract. However, that's a subject for another blog post!
Ultimately, there is a desired capability and the system doesn't deliver that. So express the bug in a positive manner. Identify what the desired capability should be. Write a story for it and prioritise it on the backlog.
Most teams have a limited resource capability, so it's the customer’s choice whether they fix bugs or implement new stories. They need to balance the benefit of fixing bugs against the benefit of other new capability. The choice is for them, but it is the duty of the delivery team to express the impact of that in terms of slippage to milestones or additional resource requirements.
I'm an experienced Agile project manager and am particularly interested in governance and contractual issues. I have a hands on approach and have been running and coaching Agile teams since the late 90’s.
WHAT WE'RE SAYING
24
MAY
I get asked the question ‘who is your favourite 19th century Prussian Field Marshal’ quite a lot, as I suspect you do as well. There are of course several great contenders for this title, but my vote has to go Helmuth Von Moltke the Elder. Why? Because of his contribution to the concept of dynamic planning! Trying to convince people that planning is a continuous and never ending process and not something that’s completed at the start of a project is a constant challenge for me and I will grab any support I can get.
ARCHIVE
- May 2013 (5)
- April 2013 (4)
- March 2013 (2)
- February 2013 (5)
- January 2013 (4)
- December 2012 (7)
- November 2012 (8)
- October 2012 (11)
- September 2012 (9)
- August 2012 (7)
- July 2012 (12)
- June 2012 (5)
- May 2012 (11)
- April 2012 (9)
- March 2012 (4)
- February 2012 (5)
- January 2012 (6)
- December 2011 (5)
- November 2011 (6)
- October 2011 (7)
- September 2011 (10)
- August 2011 (4)
- July 2011 (8)
- June 2011 (9)
Comments
31 Jul 2012 21:55
Couldn't agree more - been working this way for several years. However, I do enourage teams to track bugs as a KPI and ask teams to understand how a bug escaped. With one of my teams, I have asked them to pick two bugs per sprint and review how we might have avoided them arising. The idea is to change behaviour to drive up quality and efficiency. Often the root cause can be traced back to the way the story was introduced to the team and the questions the team asked (or failed to ask).
replyPost new comment