Tip #3 : Simplify - Don't over prioritize!

4:25 PM / Posted by Andy Harjanto /







It's easy to use priority as a way to express the importance/urgency level of a work items or bugs. Priority 1 or zero bugs are normally items that we need to fix it immediately, while other priorities; we'll assign a priority number depending on the urgency or certain conditions (nice to have, solve it later, etc). If you find yourself and your team members arguing over what priority should be given for an issue/bug, it is time to simplify your process.

After years of running many small or big projects, I experienced over and over again that lower priority bugs/issues will end up being ignored and never get visited again. And sadly, when we have a chance to visit again at the beginning of milestone, the bugs may already obsolete or the requirements have changed. I use the following process to track project work-items/bugs that I find to be much more effective. This process not only can be used in software development, but also on personal or group collaboration task oriented team work:


(1) Simply, separate bugs into 2 buckets:
· Bucket A: issues/bugs that we will fix this period (which should be a short one - my preference is 1 week).
· Bucket B: issues/bugs that we won't fix this period (e.g won't fix this week). If the issues are pretty large, break into smaller pieces. However if the issue's resolution is beyond your control (e.g "Approval from the government"), you may use a separate list to track it.

(2) You should triage and discuss issues/bugs every day with your team. We find by discussing new bugs every member of the team is informed and often offer good solution. Decide at that point, whether the new issues/bugs should be in fix this period, or beyond this period.


(3) As we approach toward the end of the period, if the issues/bugs aren't that many anymore, you may want to consider moving some items from Bucket B into Bucket A, or vice versa if issues cannot be completed during this period.


(4) At the end of period (e.g at the end of the week), start the cycle over again. Decide issues/bugs that the team you will tackle this period (e.g this week). At the cycle starts again.

While you're doing the iteration, keep the following guidelines in mind:

(A) Make the simple! Create a simple list. Do not overdo with creating unnecessary fields that you won't use. For example, “How's this issue found?”, “Which area this issue belongs to?” If you never use this data to do useful analysis or useful tracking, don't ask the user. It's a waste of everyone's time. The following 4 fields are sufficient enough for most cases: Issue Description, Status, AssignedTo, Bucket.

(B) When decides the length of period, reasonably short period is preferable. For me, I like one week as the length of the period. It's better to complete many small tasks to feel good progress being made as opposed to large tasks for longer period. In addition a compress time-frame will make the team more focus. One will react differently if one is given to complete the same (reasonable) task for a week vs for a month.


(C) End-Game. Everybody should know the end game. The period that defines in #B is not the end game period. You should come up with reasonable and specific objectives as a milestone. For example, by the May 25, we will be able to a) Register to our web site (b) Sign-in using username and password, and two-form authentication (c) Send messages from mobile phone, etc.

I'm not strongly against using priority; the problem I have is hard to get consensus of priority level sometimes within the team if we don't have clear guideline. My bigger problem is the priority does not tell you the time to complete. One could argue that we can use milestone to impose the time line, the problem with this approach is if the milestone changes, should we need to adjust the priority as well? However, I like the simplicity of two simple buckets that everybody can simply understand.

An online collaboration service, called Guppers (http://www.guppers.com/), allows you to create a customize list that are accessible for all members in a group or organization. In fact, Guppers team uses their own list to track bugs, feedback from customers, new ideas. One of the features this site has is to allow notification via Email or SMS, if the issue is assigned to you or change its status. The site is free for everyone. A quick overview is on http://www.guppers.com/learnmore.aspx

Disclaimer: Yes, I'm the Co-Founder of this site.


Labels: , , ,

0 comments:

Post a Comment