May 1, 2012 at 9:20 am
We have a variety of database related projects and tasks in the pipeline and I'm trying to put together a system to rank and prioritize them so we can tackle the items in a logical order and the ones that don't make sense (perhaps someone's pet project) fall behind ones that impact the business more. Here are some of the criteria I've thought of:
- Financial benefit (direct result of more profit or less loss)
- Security (tighter control, more auditing)
- Performance (faster, fewer executions, less resource usage)
- Scalability (ability to handle greater future load)
- Integrity (Data integrity, consistency)
- Iterations (Man hours to complete)
I thought I'd rank each project 1-5 in each area, then multiply the value by an "importance" factor (i.e. if security is paramount, a "5" there is twice as influential in the score than a "5" in Performance) and sum them up. Since Performance and scalability are frequently related, they would probably receive smaller importance factors than the other items.
Do you have a different methodology that works for you, or other criteria I should add?
Thanks,
Chad
*Edit: Added Iterations to the list
May 1, 2012 at 9:41 am
Scrum meetings with business stakeholders and sprints is how I prioritize. Some projects take more than 1 sprint, moreso for a DBA than for a dev, but the basic concepts of the methodology work beautifully.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 1, 2012 at 9:58 am
Thanks Gus. Can you expound a little? My understanding of a scrum (which I'm sure is insufficient) is that it is used to flesh out the details of a project - either high-level to determine feasibility and resources, or sufficient detail to make assignments and start immediately. I'm trying to develop a system that will help us determine whether it is time to go back and pay off "development debt" that we incurred because we didn't have time to do it the way we wanted the first time or start on the next new feature. I also have 8-12 teams (depending on how you define them) vying for resources and I need a non-subjective way to line them up so that understand we are not playing favorites.
Thanks,
Chad
May 1, 2012 at 10:26 pm
Chad Crawford (5/1/2012)
We have a variety of database related projects and tasks in the pipeline and I'm trying to put together a system to rank and prioritize them so we can tackle the items in a logical order and the ones that don't make sense (perhaps someone's pet project) fall behind ones that impact the business more. Here are some of the criteria I've thought of:- Financial benefit (direct result of more profit or less loss)
- Security (tighter control, more auditing)
- Performance (faster, fewer executions, less resource usage)
- Scalability (ability to handle greater future load)
- Integrity (Data integrity, consistency)
I thought I'd rank each project 1-5 in each area, then multiply the value by an "importance" factor (i.e. if security is paramount, a "5" there is twice as influential in the score than a "5" in Performance) and sum them up. Since Performance and scalability are frequently related, they would probably receive smaller importance factors than the other items.
Do you have a different methodology that works for you, or other criteria I should add?
Thanks,
Chad
Hi Chad... long time no see.
Before you get into all the stuff you mentioned, when's the last time you did a successful restore on your "Bread'n'Butter" databases? When's the last time you checked to make sure that [font="Arial Black"]all [/font]of your databases on [font="Arial Black"]all [/font]of your servers are on maintenance and backup plans? When's the last time you tried to fail over to the DR site and then back? Do you even have a DR site? A DR plan?
My recommendation would to be to change "Integrity", which includes all of those things and more, to a 10 out of 5 and no one works on anything else until that task is complete. Seriously.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2012 at 6:17 am
As far as understanding Scrum goes, you'll be better off researching it yourself. There's a lot to it. It's mainly about breaking things up into pieces that can be delivered fast, and about flexibility. But that's like saying databases are just rows and columns. There are details that matter. They're all online. Start with Wikipedia's article on it, go from there.
On Jeff's point about making reliability and recoverability your top priority - if you're the DB Admin, that's definitely true. If you're mainly a DB Dev/Architect, that might not be applicable. But it doesn't matter how well tuned your databases are, if they're offline because the server has crashed, your DR plan failed, and your backups are unrecoverable.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 2, 2012 at 8:43 am
Jeff Moden (5/1/2012)
Chad Crawford (5/1/2012)
We have a variety of database related projects and tasks in the pipeline and I'm trying to put together a system to rank and prioritize them so we can tackle the items in a logical order and the ones that don't make sense (perhaps someone's pet project) fall behind ones that impact the business more. Here are some of the criteria I've thought of:- Financial benefit (direct result of more profit or less loss)
- Security (tighter control, more auditing)
- Performance (faster, fewer executions, less resource usage)
- Scalability (ability to handle greater future load)
- Integrity (Data integrity, consistency)
I thought I'd rank each project 1-5 in each area, then multiply the value by an "importance" factor (i.e. if security is paramount, a "5" there is twice as influential in the score than a "5" in Performance) and sum them up. Since Performance and scalability are frequently related, they would probably receive smaller importance factors than the other items.
Do you have a different methodology that works for you, or other criteria I should add?
Thanks,
Chad
Hi Chad... long time no see.
Before you get into all the stuff you mentioned, when's the last time you did a successful restore on your "Bread'n'Butter" databases? When's the last time you checked to make sure that [font="Arial Black"]all [/font]of your databases on [font="Arial Black"]all [/font]of your servers are on maintenance and backup plans? When's the last time you tried to fail over to the DR site and then back? Do you even have a DR site? A DR plan?
My recommendation would to be to change "Integrity", which includes all of those things and more, to a 10 out of 5 and no one works on anything else until that task is complete. Seriously.
Hi Jeff! Looking forward to seeing you again in the fall! I agree with your analysis and that kind of omission would rank high on almost all the criteria across the board. I just started a new job, at my last gig we tested the backup/restore weekly (refreshed from Prod to Dev/Test/Pre), and it was really good to know that the backups were usable. I'm hoping to implement something similar here for a regular check in addition to a full blown disaster test. I intended integrity to be more along the lines of missing unique constraints, foreign keys or incorrect use of datatypes (dates in a varchar). Perhaps I need to change the term.
PS - I love the "10 out of 5" - made me laugh!
Chad
May 2, 2012 at 9:13 am
Gus - I've done Scrums before but I'm not seeing how they would help with prioritization, perhaps we were using scrum incorrectly. We would Blitz (hope this is the right term) to get a general idea of the size/scope of the project (e.g. uhhh.. this is 200-300 man hours), but there needs to be something after that to compare and rank projects so you know which one to work on first - do you refactor and normalize this group of tables (performance/scalability), add new feature "X" (financial profit), design new load-testing for a upcoming event (scalability), or send the team to training on some new technology? I'll go out and read some documentation on Scrums - if you are suggesting it, I'm sure we've been doing it wrong.
I'm adding iterations (man-hours) to the list, that is definitely a factor to consider as well.
Chad
May 3, 2012 at 8:39 am
Chad Crawford (5/2/2012)
Gus - I've done Scrums before but I'm not seeing how they would help with prioritization, perhaps we were using scrum incorrectly. We would Blitz (hope this is the right term) to get a general idea of the size/scope of the project (e.g. uhhh.. this is 200-300 man hours), but there needs to be something after that to compare and rank projects so you know which one to work on first - do you refactor and normalize this group of tables (performance/scalability), add new feature "X" (financial profit), design new load-testing for a upcoming event (scalability), or send the team to training on some new technology? I'll go out and read some documentation on Scrums - if you are suggesting it, I'm sure we've been doing it wrong.I'm adding iterations (man-hours) to the list, that is definitely a factor to consider as well.
Chad
A standard part of Scrum methodology is having Sprint Planning Meetings and Sprint Review Meetings. The sprint planning is done with devs and business stakeholders in attendance, usually including some rep(s) for senior management.
In those meetings, you go over the backlog and prioritize the tickets in it. It's already been broken down to deliverables that could, each one, be done in a single sprint. The decisions made are priorities and sequences in that meeting. Each item in the backlog is given a priority.
It's usually kept very simple. "Here's a list of our backlog tickets, which ones are critical, which are important, which are medium, which are nice-to-have, and have any become no-longer-desired?" As business plans evolve, some might move out of the stack completely, no longer desired, and can be retired from the backlog. Others might move up or down in priority.
Then you take the list, sort it by descending priority, and, using a "points per sprint" system, you work out what goes in the upcoming sprint and what doesn't. If you have the capacity to do 80 points per sprint, and the top 10 items on the list come out to about that, then you plan to do those 10, and everything else stays in the backlog for the next meeting.
New items coming in, unless they're actual emergencies (either disaster response or urgent opportunities), go into the backlog and get prioritized in the next sprint planning meeting.
That allows you to keep up with changing priorities. What was "nice to have" a month ago might be either "urgent" or "no longer desired" this month, as business needs evolve. So you need to meet with some frequency. The most common is every 2 weeks. And it has to be a meeting that includes business stakeholders, so they can battle over priorities without devs having to second-guess the actual business needs.
It's very simple to implement, and makes the whole process very transparent to both the devs and the business stakeholders and senior management. Nobody is sitting around wondering "I asked for this new feature a month ago, why hasn't it been delivered yet?"
Make sense?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 3, 2012 at 7:48 pm
That is an awesome explanation Gus, thank you for taking the time to write it out. I like what you've done and it's similar to the direction I was headed. When you categorize the tickets as Critical, Important, or Nice to Have, do you use a formal system, or just have everyone kinda vote and discuss until they reach a consensus? Do you ever have one individual arguing about how item 1's performance improvement is more important than item 2's potential-but-not-likely security hole while another individual has the opposite opinion? I could see that happening for us and the meeting getting long as they worked out the priority for a single item. If you haven't run into that, maybe I'm worrying too much.
I was thinking of doing something similar to a "House of Quality" where management gives weights to concepts they feel are important and we rank bugs, features, and other tasks according to how well they satisfy management's directives. It removes some of the subjective ranking and makes sure that as the list gets long or priorities change we still have an accurate view of what to work on next. I'm hoping that would also facilitate agreement since it is more data driven, everything has a defined "value", and will (at least theoretically) be worked on at some point when it bubbles to the top of the list.
Thanks,
Chad
May 4, 2012 at 7:01 am
Generally, a consensus is easy to get if people just sit down and communicate about it. Arguments are more likely where open communication isn't possible/allowed.
If you have someone who's personally confrontational and argumentative on a compulsive basis, that's different. But most people involved will be professional about it.
The whole idea is keep it simple. Assume the people involved are intelligent, competent pros, assume communication can resolve differences of opinion/priority, and you'll generally do well.
Expect the first few meetings to be a bit more rough-draft than later ones will, so they'll take a bit longer. People rapidly get used to the concept, traditions and the like get adopted, and a culture will grow out of it, and later meetings will smooth out just by the nature of the beast.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 4, 2012 at 9:15 am
Great advice from Gus, but one thing I'd also add to my list to circle back on is to make sure that you round robin to all groups before too long. When you prioritize, it's easy to have something fall to the side over and over and never get done.
May 4, 2012 at 9:31 am
Steve Jones - SSC Editor (5/4/2012)
Great advice from Gus, but one thing I'd also add to my list to circle back on is to make sure that you round robin to all groups before too long. When you prioritize, it's easy to have something fall to the side over and over and never get done.
If the advocate for a project or item can't be bothered to come to the sprint planning meetings, then it's highly likely their item will not ever be given high enough priority to make it onto the list of what will actually be done. Outside of that kind of circumstance, it's very unlikely that something will fall through the cracks like that.
The usual practice is, every two weeks, you have a planning meeting. The scrum backlog, which consists of every request made up to that time, is put up where everyone can see it, usually by use of an overhead projector. This is commonly in the form of an Excel spreadsheet or something comparable. It lists EVERYTHING that's been officially requested, by any accepted channel.
Everyone in the meeting, which usually includes anyone with any skin in the game on that list, usually from multiple departments, and usually including at least one rep for senior management, discusses the prioritization of the items on the list.
If someone has a ticket on that list that just keeps getting downgraded in priority every week, odds are the item really is low priority. It's possible, if nobody ever shows up to advocate an item, or if they're too shy to speak up in an open meeting, or through vicious politics (rare, but it can happen), for something to get lost in the shuffle indefinitely, but it's much less likely than if you're relying on people in the dev team to remember that your item matters.
Since the list would normally have request-date on it, anyone can point out, "Hey, item number 63 has been on the list for months and keeps getting bumped off the bottom of the priorities. Joe, is that yours? Does that need to be upgraded?" Not an uncommon thing, especially if there are people in the meeting who are more neutral to any interdepartmental politics. Often, that's part of the role of the senior management rep, or of the scrum master in the dev dept.
That's part of the purpose of the meetings. To make the whole prioritization process very transparent to everyone who cares about it for whatever reason.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 4, 2012 at 9:36 am
You may be right. I haven't done enough formal SCRUM to know. But I have seen things slip down the list. It's not that someone doesn't advocate, but that there are people loudly advocating for other items, and for higher priority items.
My point was that a strict prioritization based on benefits ignores the human aspect. Sometimes you need to do a lower priority, or less important item to make sure that you show you are considering a particular group's needs.
I'd hope something doesn't constantly get knocked down, but I'd just add a note somewhere to review periodically if there is a particular system/client that is being ignored.
May 4, 2012 at 9:45 am
During the Sprint planning, as the group is selecting tasks to work in the next Sprint, it is possible for the team to select lower priority tasks based on capacity. Another thing to be considered is that some high priority tasks are dependent on others being completed first, again I've seen this as well.
I have also seen additional tasks pulled into a Sprint when other tasks were completed sooner than expected (not as difficult to complete as originally speced) and others dropped as some tasks took longer than speced.
May 14, 2012 at 7:32 am
Steve Jones - SSC Editor (5/4/2012)
You may be right. I haven't done enough formal SCRUM to know. But I have seen things slip down the list. It's not that someone doesn't advocate, but that there are people loudly advocating for other items, and for higher priority items.My point was that a strict prioritization based on benefits ignores the human aspect. Sometimes you need to do a lower priority, or less important item to make sure that you show you are considering a particular group's needs.
I'd hope something doesn't constantly get knocked down, but I'd just add a note somewhere to review periodically if there is a particular system/client that is being ignored.
The problem with "strict prioritization based on benefits" that "ignores the human aspect" is that all value is subjective and all priorities are based on human aspects. I get what you're saying, but there is no such thing as an objective value. That's basic economics, and applies here.
Yes, it is possible for this kind of planning and operating to ignore something that would have actual value to the business. ANY human system has that flaw. This is just much less likely to do that than any other system I know of.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply