Goals for 2020 and 2019 recap

Last year Ashlee and I made one goal really that I can remember because we talked about it and looking through my old blog posts I couldn't find anything about goals for 2019.  The one goal we did have was that we wanted to make $200,000 in 2019.  We came up just short at $175,408.40.  A good chunk of that came from my excellent job, but we also did a tax free cash out refi of our home, and then of course we've been doing flips of houses for the last year to make up the rest.  Pretty cool that we got that close and unless we change the doing of flips from a hobby/business to a legit business I don't see that repeating itself in that exact same format.

A buddy of mine and I are going to try and really see if we can't make doing multifamily investing here in SLC work.  It'd be soooooo awesome if we could so we're going to start working on that.  We need to build up our team, i.e. property manager, banker, brokers for off market deals, and contractors.  We're going to start looking for them and inviting them to present at our meetup we've been holding for the past year.

My brother introduced me to process goals instead of goals several years ago and so I'm not really sure I have firm goals for the coming year, but want to continue the meetup, mastermind groups, and reading on real estate.  We're going to keep doing flips.

On the flip front we want to work on getting a heloc setup on my mom's properties so that when we do flips we aren't paying so much interest on the hard money and that'll save us/make us thousands more on the exact same deals as compared to last year working on those homes with hard money.  We're also going to partner with my mom and have her get her realtor's license so that we can do more upfront quick analysis on comps of potential flips in the future to help mitigate picking up one that might not sell for what we were hoping for in the end and beginning.

This coming year Ash and I do have the goal to have a great room remodeled in the back of our house.  So we gotta start saving for that and begin clearing out the existing space and figure out where to put what we have in there elsewhere.

I think that is most everything.  Next year we want to take the kids to disneyland so we're gonna work on that then :)

Big user stories

Sometimes as a product owner you run into the problem of having to deliver a large piece of a project.  As mentioned on a previous post you want to avoid going to technical and constraining a dev team to follow what you’ve written when instead a story is the beginning of a conversation and isn’t a commitment to exactly how something should be done.  With a user story though you don’t want it to be too big and so you need to break it down into manageable parts. 

If for example you need your team to create a new micro-service to process requests for information you don’t want to write a story that doesn’t create any value once completed.  An example of this would be writing a story that addresses the need to create a database for a user to send, receive, and update information from.  Instead you’d write a story that starts perhaps with the first part of the process, i.e. send data.  With this broken out into its own story it should be discussed with the dev team that while we know that doesn’t encompass creating a database, receiving info, or updating info they will inherently know or be explicitly told that a database needs to be created in order to complete this story.  It should be noted that the very first story will also be front loaded with initial set up and configuration of other things and so it may be larger than subsequent stories.  That is ok though because we want a story to be able to stand on its own in terms of value being delivered even if it is only one portion of data being worked on, in this case sending information. 

What to do and not do when writing a user story

When writing your story don’t include the “How” it should be done.  That is up to the dev team to figure out the best way to do that and then create tasks/sub tasks to complete those things.  Dipping your toe in the “How” waters can lead to constraining a story to follow what you have written.  You also run the risk of getting too involved with the details of how the story and value is to be delivered and that can lead you to spending time on things that don’t need your attention, which then detracts from continuing to gather requirements and prioritize which valuable things need to be done first.

When writing acceptance criteria, it is important to write them so that you tell the developer and QA resources what you want them to test against.  All acceptance criteria should be testable.  A bad example would be, “X technology passes a flag to X other technology so that a customer doesn’t have tax withheld from their order”.  Instead a better example would be, “Demonstrate that a customer can click a button to then have taxes withheld from their order.”  The first example is too specific and limiting.  The second lets the dev team decide how to make something happen but is easy to demonstrate that it works or not, i.e. if it was done right this would be the result.