Web App Project: Sprint 5

My goal this week was to regain confidence by ensuring some success, so I focused on only one story, and, it worked!… I believe we reached the point where I know the idea is feasible and it is also no longer vapourware. Once I had got the button that checks the speed for all the websites working, I became confident again and decided to take on more items, first fixing the bug on the login, which now brings the customer directly to the site comparison table and since I was on a roll, I decided to put in a further story, to display the results in a table which I wanted to be sortable too. Thankfully it’s all done, which brings the velocity this week to five story points. The stories/features I’m working on sound simple and these always should be, but, if you don’t know the Ember framework, and I don’t, then that can take hours to figure out.

It might be worth also reiterating, that each sprint is just a week long and I planned to spend between 5 and 10 hours working. Looking at my accountability sheet, I see I am contributing a little more. The average is 13 to 18 hours per week which includes time on; research, programming, writing this blog, recording video for youtube and planning. It is not recommended you track time in Scrum for various reasons, but, if you’re following this project, it might be interesting.

The cost of the Google cloud services for the first 2-weeks operation is a total of about 25 USD. We only have about another 40 days of the 275 USD of free credit; I wonder if it will change much and will keep you posted.

google container service billing

For the next Sprint, I want to deploy a fully working version of the application. We require an SSL certificate on the backend service, which is the goal next week. I will either get the Google service working using HTTPS or get the web app to call the PageSpeed service directly.

Sprint 6 Backlog

It would be easy to spend the next couple of sprints working on the backend, but it would probably be a mistake to ignore the overall design. Having a nice looking tool is usually a substantial selling factor since many apps have similar features. Therefore I moved these items to the top of the backlog. Unfortunately, the total story points have only gone down 1 point, and we have 39 to go. The velocity will not be enough to complete them all. The project will conclude at the end of sprint 8, but that should suffice to get a nice prototype deployed.

The positive side of this I think is we can expect to have a functioning app which can measure speed and usability and compare several websites. It would allow early feedback to come in from potential customers. Who might then want it to have the comparisons automatically done every day, which could then be introduced as a paid service? 


Web App Project: Sprint 4

This week it turned into a learning fest. I spent time on each item but unfortunately, despite all the action, did not achieve any of the sprint goals the way I wanted:

  • User is able to trigger a website speed scan.
  • Displaying the results.
  • Securing the webservice.
  • Fixing the bug where login should redirect to the tasks screen.

The first two sprints of this project I struggled my way through learning Ember and spending last week on server-side was great because it just was more familiar and somehow easier. I doubt you will find a blog out there that will say it is easy to learn Ember. Reading the documentation on the main website several times does eventually help.

Keeping up with modern application development is a full-time job not to be underestimated, I think it’s become difficult to prove mastery with the constant switching between frameworks that seems to be required. A couple of years ago I would argue these were all magpie developers, but having spent a couple of years studying cloud tech and using it myself for a good year, I now understand things differently. You can never stop learning and have to like it.

For the next sprint, I want to go into laser beam focus, to regain confidence. I will continue on the feature to lookup the speed of a list of websites and to display the results. I will ignore everything else including the open bug, for which there is a workaround.

Having deployed the client on firebase, I discovered another problem, that the REST API must also be using HTTPS. I did try to set that up during the sprint but ran out of time in the end, so it will have to wait in the backlog along with other items.

The project backlog now has stories with 40 points. The good in knowing this is that we can quickly estimate how many more weeks we might need. I’m hoping an early beta version could hopefully be ready by the end of sprint 6.