Hello everyone again,

Hope your day is going great. So after playing with Trello for a good hour I have determined how I am going to structure my cards there so that they visually tell you what my priorities are though not exactly why I decided them that way, that is what the blog is for. I wanted to have four things on here that helped me figure out what needed to be done other than the obvious:

1. Agile Estimate: Determine the amount of work it’s going to take to complete the Task and/or Feature. In my case I learned that this can be either done with T-shirts or dog, represent hours or how heavy the Task and Feature is but I prefer to go with a Modified Fibonacci sequence (0,1,2,3,5,8,13,20,40,100) to represent the amount of Doubt, Complexity and Effort a card has. More on those later.
2. Business Value Estimate: Determine how much value a Task or Feature will bring to my project. Again every company has their own definition of what business value represents most of the time it’s how much money this feature will bring in. Usually the top shareholder and/or marketing people are there to talk with the Product Owner and/or team to figure this out but since I am everyone at the moment, I get to make this call muhahaha.
3. Kano Analysis: This is a little tricky to explain, from my point of view this analysis represents how a viewer would see the card. Whether they see the card as Basic necessity for a project to be successful at all or is something that makes people Delighted to see something in a project. It basically tries to take feedback from your users or clients and see what they perceive is needed for the project. Here we use four labels:
   • Basic: Fundamental needs for a project
   • Delighter: Something that makes clients/users excited
   • Satisfiers: Something that may not delight someone but creates a convenience for the clients/users.
   • Frustrators: Something that makes the clients/users mad and needs to be fixed.
4. Lastly is MSCW: This is a simple acronym for Must, Should, Could, and Would. This I use to represent the technical side of things when it comes to prioritization. In some cases you have several systems that are dependant on other systems existing before they can bring their value to the forefront. For example, you can setup a storefront for developers or clients to populate items for users to buy and sell items on but if you do not have a payment system in place 1st the storefront doesn’t do anything other than show you cool stuff. So on projects that I have ran, I use this to tell my team and myself what needs to be done right now. This does end up being my primary way of telling my teams what they should be doing next as well as the biggest thing I update on a regular basis to keep the team churning.

Now these are all basic explanations for what I am planning on using but there is more I can go into with them, just not today. I will be posting more about them as I move forward.