So since I always wanted to follow an agile software development process and use scrum, but it never really took off with my jobs, I am going to do it for this site.
For those of you not familiar with agile software development, it basically is a methodology for engineering software. It is based on the idea that in the real world, requirements change, pieces of software are built on top of other software, and constant testing a working codebase is crucial.
To go a little deeper, it is fast iterations of software. So say a customer wants a web site with 100 different features. Instead of documenting and writing all requirements and test plans, developing the entire site, and then delivering to the customer some long time later, you would write the essential requirements for each feature, with testing plans, and deliver a working site with those features so a customer could see it, or so you can see it, then in your next iteration implement more features, and so on and so forth.
This helps to always have a working product, rapid delivery and updates keeps a customer happy, and breaking down requirements helps for planning and testing.
Specifically I am going to be using the SCRUM framework of this process. For the most part this assumes a product backlog (the requirements, user stories, features, etc) , and at the beginning of each sprint , or major iteration of the code, you plan which features etc, from the backlog can get into the sprint , do this and release for the end of the sprint.
 |
| Scrum |
Usually you meet each morning for 15 mins to say what progress has been made, what you are working on, and if anything is getting in your way. Since I am the entire team in this case, this will not be necessary.
This is built around a team, and hopefully one day if my site gets huge I can have one, but for now its just my way of organizing myself while learning.
My sprints will be 1 month long. Obviously I will not have HUGE iterations each month as I am one person doing this in my spare time.
I am using the Github issues tab as my product backlog. I have labeled each by priority and gave them a rough size estimate.
My priority labels are as follows:
- Critical functionality
- Cannot move on without this, 100% necessary for the site
- Important functionality
- very important, site will work without it, but is key functionality needed pre-beta
- really want
- not 100% necessary but should be included
- these can come during beta release
- nice to have
- not really necessary but something that may slightly improve user experience
The critical functionality items will be done first regardless of size, then the important. I have written user stories for each of the critical functionality items.
Users stories are the basic requirements I will be working from. They consist of the 3 C's. Card, Conversation, and Confirmation.
Card is a simple one sentence description of the feature stating who the stake holder is and why they need that feature, or what it may do.
Example: As a USER I would like a welcome email when I register to remind me of my username.
This obviously leaves out a ton of stuff, but is the basic functionality of what it needs to do.
The Conversation part is more like the conversation with the developer and the person giving the requirements to really flush it out. Mine will likely be just a rough mockup of the screen with the feature describing functionality. For this one, it may just be the email itself with a link, and some text describing what the link would do.
The Confirmation piece is confirmation that the feature works as expected. This is the test cases to ensure the feature works. For the example above it may be something like:
- On successful registration an email is delivered
- On failed registration no email is delivered
- In the email there is a link back to the home page
I actually have only written the Card part of my current user stories. After my sprint planning, which I may do over this weekend, I will write the Conversation and Confirmation pieces of the items that I believe I can fit within this sprint.
On that note, you are probably asking yourself, "How do you know what you can fit into a sprint"?. Long story short.. I don't. However I can't just give up because I am not sure how many hours I will work on this this month, and how big each item on that list is.
I looked up a bit of how to make these sorts of estimations. Basically you don't want to estimate in terms of time, like hours weeks etc. You want to estimate in terms of size. Size you say? What unit would you measure that? Well there is no real unit of a size of a software project, unless you were counting bytes or something, for this it is sort of size of the project and size of the time I think it would take me. Some sites say people estimate time based on any unit so long as the team members are aware of what is bigger than the other.
For example some teams use shirt sizes like S M L XL XXL XXXL. While others may use Fibonacci sequence like 1 2 3 5 8 12.
Me, since I am my own team in a non-professional environment, and because it feels rewarding, I am going to use beer sizes for my estimates.
From small to large:
Sampler 4.75oz
Can 12oz
Pint 16 oz
Tall Boy 24 oz
Growler 40 oz
Pitcher 60 oz
Tower 100 oz
Quarter keg 496oz
Half keg 992oz
To see what my issues look like and how I am labeling them see below.
 |
| First 11 issues on my list with labels |
You can also watch my repo, and look at my issues/code whenever you want here
https://github.com/teylewr/PlayDate/issues
If anyone thinks I said anything wrong above please let me know, so I don't continue thinking the wrong things. I am always open to feedback and constructive criticism.
