Web App Project: Sprint 8

Over the last 8-weeks, I used parts of Scrum primarily on a one man project. I used a product backlog, estimated stories, had my share of great and bad sprints, made a demo every week and even carried out retrospectives. You can certainly apply Scrum processes to small projects, even on your own, but, I would warn anyone trying to do this, that unless you have an accountability system, such as weekly meeting with a customer or product owner, then you are very unlikely to follow through.

I didn’t realise in writing the final blog on this web app project, that I’d become apprehensive. So far I’ve had no feedback through comments on my blog or youtube channel. I had hoped for an honest discussion.

This experiment was a way for me to share parts of the Scrum process without having a team, Scrum master and product owner. I’ve been trying to avoid prescribing what is right or bad, there are just too many people doing that, nobody wants to be Chet Rong, the world’s worst agile coach, which is a funny video in itself, but I can tell you from many years using Scrum myself, that even badly implemented you can still reap benefits.

Anyone considering using Scrum processes should expect resistance if trying to get freelancers and contractors to work in this kind of team. I think that it boils down to them worrying about being micro-managed. I can assure you that this is not the case and that through the planning and retrospective meetings you both have a good 2-way communication from business to IT, vice-versa, and will be making improvements on a sprint to sprint basis.

Speed Comparison App

For this project, I only used tech that was new to me, including; the Ember.JS framework for the app, Node.JS for a microservice, Docker,  Google Cloud Platform, Kubernetes and NGINX. It wasn’t until the last couple of sprints I began to gain traction on the frameworks I had chosen. For example, the goal in the last week was to integrate a bootstrap theme which I completed relatively quickly. Obviously it takes a bit more work to get an application to look really great.

With any new technology, framework or programming language you’re learning there are always going to be surprises. Just this week, for me it was figuring out the Ember environment settings. Documentation on taking secrets like API keys out of source control don’t seem to be freely available, answers I only found by re-reading Ember documentation a couple of times.


Although I’ll be taking a break for a couple of weeks from the web app project. I took an hour to go through the product backlog. Now it might look like the stories are jumbled up. This reflects the last planning exercise I did.

Product Backlog

Using Critical Path Analysis (CPA) is not common on Scrum projects, but the technique can help you decide on future sprints.

Critical Path Analysis

Something I’ve not seen anyone use or talk about before. It can be helpful in working out and identifying dependencies, even if it is miss-leading on the total time required to complete work.

There are currently 4 epics:

  1.  Usability (purple) – adding progress bars when processing website speed and confirmation on delete.
  2. Dashboard (orange) – providing charts to make it easier to analyse the changes in site rankings.
  3. Scheduled Comparison (blue) – Checking the page speeds every night and sending notifications to users when there is a change.
  4. Monetization of app (green) – Make it possible for customers to purchase the service which will provide features like the scheduled comparison.

Following the critical path analysis I drew up the following sprint plan which looks like there will need to be at least another 8 to 10 sprints.

Sprint Plan Visualisation

I’ve also included a velocity chart which documents the number of story points I tackled in each sprint. This chart can also be a little miss-leading and you can see in Sprint 7 what seems to be a dip in productivity. However, bugs that need to be fixed cannot be estimated in JIRA. In that Sprint I deliberately took only one story, to be sure I would complete all work.

Sprint Velocity Chart

To wrap up on the infrastructure, I think Firebase is fantastic for rapid prototyping. The Google Cloud Platform is also very powerful and the fact they provide free credit allows you to get a good idea of the services they provide. The billing is currently showing that $112 of the $300 free credit have been used which will expire in about 3 weeks. For small businesses this might seem a lot, but, you are getting access to a world-class data centre which is not comparable with setting up your own servers in-house.

That’s it! Let me know what you think of the 8-week project and web app, in the comments below! If you have any feedback at all, I welcome it.


Web App Project: Sprint 7

If you’d like to try the web app out, it is available here There were two goals this week; I was looking at improving the usability & design and fixing a logical bug where users would be overwriting each other’s data.

I’ve not needed to learn much about Bootstrap yet, but this week I quickly had to get to grips, luckily after spending some days surfing and not getting so far, I found the Pluralsight course Bootstrap 3 by Shawn Wildermuth. It allowed me to correct some problems with the navigation menu and site speed result table. Also, I checked out some sites offering themes, like Bootswatch, and even tried to integrate into my Ember app, but, that didn’t work unfortunately.

I like Googles Firebase NoSQL database a lot. Similar to standard databases you are applying rules on the server side, which they solved in an incredibly efficient way. The bug I mentioned at the beginning of users overwriting each other’s lists was a matter of placing their data under a user directory using their id, which I found out about in a couple of helpful blogs posts. Luckily I also consulted my Ember expert Alexandr Opak who came up with a much simpler solution, which again for me at least highlights that code like that is going to require refactoring neverminding the perils of copy and paste from the internet.

Visualising Software Architecture

The following architecture diagram will let you understand the overall environment and high-level technology choices, which I didn’t have time to update for a couple of weeks now.

Everything is on Google Cloud Platform and so far $70 of free credit has been used on infrastructure. Firebase has a different pricing and is currently free.


Also worth a mention on Google Cloud Platform is that it notified me this week that the new NGINX service is not requiring so many resources as given. A great feature in the form of a pop-up offered me to reduce the compute resource and thus save money. I’ve not seen that on other cloud platforms yet. It certainly makes sense as it currently roughly looks to be costing about $25 per week.

Resize Instance And Save Money

For the last sprint, I have decided I want to look at compatibility on mobile devices (2 points) and try to integrate a bootstrap theme (2 points). The total story points for the sprint is 4. I spent a little bit of time going through the backlog tidying up the stories and creating epics where-ever a feature would require more than one sprint.  I’ve grouped the stories into 3 epics; usability (11 points), scheduled speed comparisons and notification (22 points) and app monetization (13 points). With the current velocity which on average is 4 points per Sprints we would need about 12 sprints to implement everything. Remember I only planned to spend 5 to 10 hours a week on the project. Working full-time with a team you could easily get there in 2 to 4 weeks. As long as you estimate your stories every week, then you will always be in a position to estimate the time required and budget appropriately.