If you're wondering who owns the product patches, who determines when a patch will be done, what will the patch cover and how it will be delivered, the answer to all these questions is summed up in one word - Support
You don't depend on CTO Development or Operations manager to forward the requests and make developers do the actual work of creating patches. Simply use the Scrum process we have set in place and get your patches delivered just the way you like them - medium rare or well done
Below you will find 3 easy steps to help you help customers
1. Identify the need
As you are directly in contact with customers you can feel their pain and determine what issues trouble them the most; no one else can do this for you, not CTO, not QA, and definitely not developers who created the issues (although inadvertently) in the first place
Ask yourself the following questions:
a) How many customers have been affected?
b) How serious is the bug at hand? (see How to determine your own bug severity)
c) Does the identified bug have a workaround you can offer now to the customer?
d) How fast does the customer need the fix?
e) How many "invisible" customers who didn't contact you could have been affected by the bug?
f) How brand-damaging is the bug?
g) Will patching the bug now help the company to keep existing customer or gain a new one?
Compile and maintain the list of bugs-for-patching candidates daily; make sure you include only bugs that customers actually need. Remember: not all bugs are created equal - a High severity bug that has a workaround isn't necessarily instant candidate for patching
2. Make the request
Now that you have a neat list of one or more bugs that obviously need to be patched ASAP, create a patch request for corresponding product: just add/update a Product backlog item directly in the product-owning developer team's Product backlog
If you are requesting a new patch, create a new Product backlog item and describe in details what exactly you need delivered - specify all bugs individually, their ID, severity and description
If you have found additional bugs for the same product that need patching, append them to previously created Product backlog item if it is still open
Send an FYI to Product owner and the developer team about added / changed Product backlog item in their Product backlog
3. Deliver
You've done your job - don't worry if or when will you get the actual patch sent to you, this is now up to the developer team (they also have a system and a set of rules to follow). However for reporting needs you should still maintain a list of all patches you requested and when you requested them
As soon as you receive the patch with requested bug fixes, directly contact the customers who reported the issues and make them happy
Q/A
Q: I need to get a patch for this Medium severity bug as customers desperately need the fix. However rules say I can only request a patch for Critical and High severity bugs?
A: Why do customers desperately need the fix? If this is so obvious, are you absolutely sure your bug should be Medium severity in the first place?
Q: I requested Critical severity bugs patched and the customer needs this yesterday. Developer team just started a new two-week sprint without the patch goal included so this patch won't be done in another two weeks - can I yell at developers to speed this up?
A: No - don't yell and don't go pulling on CTO or Ops manager skirt. Developers also have a set of rules to follow and one of the rules is that Critical bug fixes must be delivered in a week's time even if it means working outside of the Sprint during allocated ad-hoc time. You'll get your patch sooner than you think
Q: I always request new patches each Friday once I build up a list of obvious patch candidates but customers don't want to wait 3 weeks to get the patch. What can I do?
A: Start by requesting new patches as soon as you identify bug candidates for patching, not once per week - there's nothing limiting you to do this daily if needed
Friday, August 31, 2012
Thursday, August 30, 2012
Scrum tales - part 4
As a Scrum team you just finished your first Sprint and need to start a new one? Look no further and see below
Wrapping up a Sprint
1- Sprint review
At the end of the Sprint it is important to present the results to your Product owner in a Sprint review meeting. This meeting is informal in nature so to speed this up just send in Sprint summary email specifying all Product backlog items (goals) and their status:
a) Done - good, make sure that Product owner can see the results
b) Not done - explain why the goal wasn't achieved
In the case of #b, reasons can vary from having a surge of ad-hoc tasks interfering with the Sprint priorities, goals being blocked by external impediments, to Scrum team members being abducted by aliens; in any case the reason must be clearly explained. Having clear reasons stated will help both Product owner and Scrum team to adapt future Sprints to prevent this from happening or at least to plan ahead: plan more time for ad-hoc priority tasks, work out the impediments in advance, or prepare supplies and go underground in case of an alien invasion
Important: unfinished Product backlog items must be moved into the new Sprint if they are still of high enough priority and be 100% finished there
2- Sprint retrospective
This meeting is organized by the ScrumMaster and whole Scrum team should attend. It must cover the answers to the following questions:
1. What worked?
2. What didn't work?
3. What will we do differently?
Log answers to the above questions in your Scrum tracking system and apply them in the next Sprint. It is necessary to adapt your self-organization as a team to prevent or predict impediments and make the next Sprint achieve all defined Sprint goals
Starting a new sprint
1) Make sure your team Product backlog is up-to-date; if you have uncertainties about Product backlog items or their priorities contact your Product owner early
2) Change ScrumMaster in the team - this is mainly up to your team to decide, but changing ScrumMaster will allow you flexibility and make sure anyone can handle the responsibility. It is not an excuse to stop sprinting if specific team member who knows how to be a ScrumMaster is away
3) Conduct a Sprint planning meeting with the whole team and prepare new Sprint backlog. Although Sprint backlog is ownership of the Scrum team and Product owner shouldn't interfere, still send the final variant in an email for Product owner to see and to at least have a reference when discussing any future related issues
Wrapping up a Sprint
1- Sprint review
At the end of the Sprint it is important to present the results to your Product owner in a Sprint review meeting. This meeting is informal in nature so to speed this up just send in Sprint summary email specifying all Product backlog items (goals) and their status:
a) Done - good, make sure that Product owner can see the results
b) Not done - explain why the goal wasn't achieved
In the case of #b, reasons can vary from having a surge of ad-hoc tasks interfering with the Sprint priorities, goals being blocked by external impediments, to Scrum team members being abducted by aliens; in any case the reason must be clearly explained. Having clear reasons stated will help both Product owner and Scrum team to adapt future Sprints to prevent this from happening or at least to plan ahead: plan more time for ad-hoc priority tasks, work out the impediments in advance, or prepare supplies and go underground in case of an alien invasion
Important: unfinished Product backlog items must be moved into the new Sprint if they are still of high enough priority and be 100% finished there
2- Sprint retrospective
This meeting is organized by the ScrumMaster and whole Scrum team should attend. It must cover the answers to the following questions:
1. What worked?
2. What didn't work?
3. What will we do differently?
Log answers to the above questions in your Scrum tracking system and apply them in the next Sprint. It is necessary to adapt your self-organization as a team to prevent or predict impediments and make the next Sprint achieve all defined Sprint goals
Starting a new sprint
1) Make sure your team Product backlog is up-to-date; if you have uncertainties about Product backlog items or their priorities contact your Product owner early
2) Change ScrumMaster in the team - this is mainly up to your team to decide, but changing ScrumMaster will allow you flexibility and make sure anyone can handle the responsibility. It is not an excuse to stop sprinting if specific team member who knows how to be a ScrumMaster is away
3) Conduct a Sprint planning meeting with the whole team and prepare new Sprint backlog. Although Sprint backlog is ownership of the Scrum team and Product owner shouldn't interfere, still send the final variant in an email for Product owner to see and to at least have a reference when discussing any future related issues
Wednesday, August 22, 2012
Self-help book: Define your own defect severity
You've found a new bug but you aren't sure what the correct severity for the defect is? Welcome to the "This is no exact science" club
Here are some general hints how to solve this question that I already shared with some of you over IM:
1) Treat Bug severity standards as guidelines - see the first line in the document, it clearly says that the document is written as guidelines and that ultimate responsibility for bugs you find is yours
2) Worried about how will Critical severity affect production, developers? Are you also worried about global warming and dying rainforests? If so, how does this help you define the severity of the bug you just found? The answer is: it doesn't
3) Wondering why your Low severity defects describing features not working still aren't fixed after two months but are considering to make this one Low severity as well? Rethink this again
4) Put yourself in the customer's shoes. What is your reaction to the newly found bug?
a) I don't like the product and I won't use it
b) This is very annoying, I won't use the product because of it... much
c) I can't use this feature as I wanted to but I see the workaround exists - kind of annoying but I'll get over it
d) I don't frequently click in the top right corner 3 pixels next to the Ok button and cause the mouse pointer to glow red - I'll forget about this by tomorrow
5) Make sure that you've put yourself into 80% of the customers' shoes - if you are thinking as someone who used to code Commodore 64 games in assembly back in the 80's and know how to get Linux distro kernel version, then a chance is this issue may only be visible to you
6) Contact your QA team members to see if the apparently Critical issue is easily reproducible by at least one more team member; maybe your VM OS stopped working after months of abuse
7) Devs insist on reducing the bug severity you've set and you're scared, best to comply? No - stand by your decision especially with facts you determined before defining the severity
8) Severity can go both ways, both you and devs have solid facts about the case. Contact analysis team for recommendation. However this should be an extremely rare case if you follow #7 above
9) Still not sure? Notice that I haven't answered any of the questions above with definite answers, when to use which bug severity. This is entirely up to YOU. As you have the ultimate responsibility for quality of our products and ApexSQL brand in general, you also have all the power needed to affect the quality with bugs you find
Note: if devs are giving you hard time, let me know directly ;)
Here are some general hints how to solve this question that I already shared with some of you over IM:
1) Treat Bug severity standards as guidelines - see the first line in the document, it clearly says that the document is written as guidelines and that ultimate responsibility for bugs you find is yours
2) Worried about how will Critical severity affect production, developers? Are you also worried about global warming and dying rainforests? If so, how does this help you define the severity of the bug you just found? The answer is: it doesn't
3) Wondering why your Low severity defects describing features not working still aren't fixed after two months but are considering to make this one Low severity as well? Rethink this again
4) Put yourself in the customer's shoes. What is your reaction to the newly found bug?
a) I don't like the product and I won't use it
b) This is very annoying, I won't use the product because of it... much
c) I can't use this feature as I wanted to but I see the workaround exists - kind of annoying but I'll get over it
d) I don't frequently click in the top right corner 3 pixels next to the Ok button and cause the mouse pointer to glow red - I'll forget about this by tomorrow
5) Make sure that you've put yourself into 80% of the customers' shoes - if you are thinking as someone who used to code Commodore 64 games in assembly back in the 80's and know how to get Linux distro kernel version, then a chance is this issue may only be visible to you
6) Contact your QA team members to see if the apparently Critical issue is easily reproducible by at least one more team member; maybe your VM OS stopped working after months of abuse
7) Devs insist on reducing the bug severity you've set and you're scared, best to comply? No - stand by your decision especially with facts you determined before defining the severity
8) Severity can go both ways, both you and devs have solid facts about the case. Contact analysis team for recommendation. However this should be an extremely rare case if you follow #7 above
9) Still not sure? Notice that I haven't answered any of the questions above with definite answers, when to use which bug severity. This is entirely up to YOU. As you have the ultimate responsibility for quality of our products and ApexSQL brand in general, you also have all the power needed to affect the quality with bugs you find
Note: if devs are giving you hard time, let me know directly ;)
Scrum tales - part 3
Let's get back to the Scrum basics for a second - I'm seeing recurring issues regarding creation of Product backlogs and Sprint backlogs:
1) My team's Product backlog items are concise and can be easily understood by Product owner:
a) "Review the handbook"b) "Implementing new CRM system"
c) "Post 3 new articles each day"
Our team will excel during the next Sprint after Product owner sees this
No - you're pretty much toast after Product owner sees such undefined and immeasurable Product backlog items - all will be rejected. Don't worry, I got your back - here's how to fix this:
No - you're pretty much toast after Product owner sees such undefined and immeasurable Product backlog items - all will be rejected. Don't worry, I got your back - here's how to fix this:
a) Don't just 'review' but instead 'review and update' or 'review and send proposal'
b) Don't work indefinitely, i.e. 'implementing' - instead just 'implement'
c) Don't 'post N articles each day' - instead 'post X articles total' and define Sprint tasks how you will do this (per day, per week, divide among team members) - this is up to you to achieve the goal
2) We're planning a Sprint but some of the tasks are pure guestimates so we'll just leave them without any estimates in the Sprint backlog and move on
If you do that, how will you know that your Sprint goals are achievable for the time allocated for the Sprint? I know that Sprints are 'owned' by teams and ScrumMaster is only making sure Scrum rules are followed - however how can Sprint burndown chart be correct if you have no task estimates in the Sprint?
2) We're planning a Sprint but some of the tasks are pure guestimates so we'll just leave them without any estimates in the Sprint backlog and move on
If you do that, how will you know that your Sprint goals are achievable for the time allocated for the Sprint? I know that Sprints are 'owned' by teams and ScrumMaster is only making sure Scrum rules are followed - however how can Sprint burndown chart be correct if you have no task estimates in the Sprint?
Instead you can do the following:
a) Plan ahead for complex and large new Product backlog items - create new ones with higher priority that will allow you to first research and learn about the technology, what needs to be done and how long it will take
b) Estimate with the help of the entire team - if you need 3hrs and your team member needs 6hrs, that means the task shouldn't be less than 4.5hrs
c) If the estimates are wrong, update them later - that is why they are called 'estimates' and you update Remaining Work for each active task on a daily basis
Scrum tales - part 2
More Scrum questions are showing up - I'm covering top ones here again for all to see:
1) Can I add new tasks to a Sprint after it has started?
Yes - you can definitely add Tasks that you find along the way for goals (Product backlog items) that you previously committed to. Tasks must be estimated, and if they are of higher priority than some existing tasks previously added to the Sprint it might cause the bottommost ones to be squeezed out and moved into the next Sprint
2) I have several Product backlog items that are of high priority but can only be done one task per day due to technical limitations. How do I work with such goals and what happens when they cannot be fully completed during one Sprint?
Just focus on completing tasks top to bottom and following their priority. If you cannot finish all the tasks in order to close the Product backlog item during one Sprint, move this item into the next Sprint and continue working on it until fully completed
3) Everyone in my Scrum team are sick, must be Measles. Can I do a Sprint planning meeting by myself?
Yes, although it is highly recommended to have as many of your team as possible present during the Sprint planning meeting. Always think ahead, prepare the next Sprint early while everyone is still healthy and accounted for. Don't wait for the last Sprint day to prepare for the next one
1) Can I add new tasks to a Sprint after it has started?
Yes - you can definitely add Tasks that you find along the way for goals (Product backlog items) that you previously committed to. Tasks must be estimated, and if they are of higher priority than some existing tasks previously added to the Sprint it might cause the bottommost ones to be squeezed out and moved into the next Sprint
2) I have several Product backlog items that are of high priority but can only be done one task per day due to technical limitations. How do I work with such goals and what happens when they cannot be fully completed during one Sprint?
Just focus on completing tasks top to bottom and following their priority. If you cannot finish all the tasks in order to close the Product backlog item during one Sprint, move this item into the next Sprint and continue working on it until fully completed
3) Everyone in my Scrum team are sick, must be Measles. Can I do a Sprint planning meeting by myself?
Yes, although it is highly recommended to have as many of your team as possible present during the Sprint planning meeting. Always think ahead, prepare the next Sprint early while everyone is still healthy and accounted for. Don't wait for the last Sprint day to prepare for the next one
Scrum tales - part 1
Developers, Support and Analysis teams have now had their first experience working with new TFS Visual Studio Scrum 1.0 template and I'm seeing Product backlogs forming, Sprint planning meetings underway
I'm still getting good number of questions, both systems (Scrum) and operational (TFS), i.e.:
1) How do I initiate a Sprint when I have 5 large Product backlog items and all are of the same priority?
You can't because you don't know which one to take first - make sure you have Product backlog items all with different priority approved by Product owner before you initiate Sprint planning meeting. No two goals should have the same priority
2) What do I do when one Product backlog item cannot be worked on in parallel, can I start the next one in the Sprint?
Yes - you can organize internally in the team in order to achieve goals you committed to the best way possible
3) Can I add tasks that include waiting on other people/teams to send me something?
No - why would you commit to a goal that you don't know you can finish? Identify impediments early and resolve them before the next sprint. If there are unforeseen obstacles that show up during a sprint, add an Impediment work item to your Sprint backlog and it is now up to the ScrumMaster to close it ASAP. Until an Impediment is closed proceed working on tasks next in line
There are more use cases and I'm sure we'll encounter even more in the upcoming weeks. I'll put them up as they appear. Everyone should feel free to post back thoughts and questions
I'm still getting good number of questions, both systems (Scrum) and operational (TFS), i.e.:
1) How do I initiate a Sprint when I have 5 large Product backlog items and all are of the same priority?
You can't because you don't know which one to take first - make sure you have Product backlog items all with different priority approved by Product owner before you initiate Sprint planning meeting. No two goals should have the same priority
2) What do I do when one Product backlog item cannot be worked on in parallel, can I start the next one in the Sprint?
Yes - you can organize internally in the team in order to achieve goals you committed to the best way possible
3) Can I add tasks that include waiting on other people/teams to send me something?
No - why would you commit to a goal that you don't know you can finish? Identify impediments early and resolve them before the next sprint. If there are unforeseen obstacles that show up during a sprint, add an Impediment work item to your Sprint backlog and it is now up to the ScrumMaster to close it ASAP. Until an Impediment is closed proceed working on tasks next in line
There are more use cases and I'm sure we'll encounter even more in the upcoming weeks. I'll put them up as they appear. Everyone should feel free to post back thoughts and questions
Subscribe to:
Posts (Atom)