How To Plan & build a Serverless Website Using S3 — PART1: Project Management

Photo by Eden Constantino on Unsplash

Table of Content

1. Introduction
2. Agile Methodology
3. Product Backlog & Sprint1
4. Kanban Board — Sprint1
5. ICE Prioritisation framework — Sprint2

Introduction

Have you ever thought about developing your own website? Maybe to share your portfolio, resume, or even your thoughts. In this post (which is divided into 3 parts), I’m going to share how my website has been developed from three points of view: project management, DevOps and AWS.

The main goal of this project was to gather the knowledge I have obtained for the last couple of months, and also share it with you. Let’s go?

Agile Methodology

For this project, I have chosen to implement Agile, more specifically the Scrum framework. The reason why is due to the project time (how long it will take to deliver), and as it is a personal project, there isn’t a due date. Besides, I see that it will always have room for improvement, and the Scrum framework absorbs well changes in the project scope. If you’re not too familiar with the Scrum framework, I recommend reading “The Scrum Guide”.

Product Backlog & Sprint1

Firstly, to define the product backlog, I had to run a brainstorming session to evaluate the basic items and tasks that I BELIEVE that was necessary to develop my website. Next, add them to your product backlog without any filter (filtering and evaluating an item during the brainstorming session may impact the creative process). You also don’t need to add all items at once, during the project you’ll feel the necessity of adding new stories to the product backlog and executed in the following sprints. Ah, forgot to mention, I have been using the software JIRA (Free version) to manage my sprints and kanban board. Alright, once the items were on the product backlog list, I have selected the basic ones to start creating the website, such as HTML/CSS templates and cloning them to my repository in GitHub (Spoiler alert for the next parts of the article).

Following that, these items were moved to my sprint backlog, which is basically the items I wish to complete by the end of the sprint. Due to my work/uni workload, I opted for 7 days of the Sprint length. Head back to the sprint backlog, note that I’ve estimated the duration of each item according to MY SKILLS since I am the PO, Scrum Master, and the dev team in the project.

Figure 1 — Product Backlog and Sprint Backlog in Jira

Lastly, the sprint backlog and goal have been defined and it has now started.

Figure 2 — Sprint Goal

Kanban Board — Sprint1

Moving to the “Board” section in Jira, a Kanban board will be shown. It is an Agile tool used for workflow visualisation in which the cards can be moved over the board according to their progress. Usually, the cards with higher priority are set on the top of each column. In our case, the highest priority was finding a template and cloning it to GitHub. Then, changing the code of the website according to my needs.

Additionally, within each card, Jira allows you to configure the estimation time, time spent, add comments and labels. I’ve added the labels: GitHub and AWS to cards related to these services, so I could later filter the tasks which only have a specific label. Hence, you can attach links to the cards, for example, tutorials or google links that may help to resolve the task. In a company scenario, each card can be assigned to a project member. Learning from my mistakes, I would recommend breaking the stories into smaller and detailed stories. This will maximise productivity and give you a better estimation of the time for them.

Figure 3 — Kanban Board

By the end of the Sprint, all items must be completed. Otherwise, the leftovers can be put either back in the product backlog or Sprint backlog for the following Sprint, depending on the PO judgment. In Figure 5, it can be seen the Sprint burndown chart, which presents the number of resolved issues against the sprint days.

Figure 4 — End of the Sprint1

Figure 5 — Sprint BurnDown Chart

ICE Prioritisation — Sprint2

To avoid being repetitive, I followed the steps shown in the previous sections but implementing the ICE prioritisation in our second Sprint. In this framework, there are three main variables:

• Impact: how much does it contribute to the goal? it can vary from “very low” to “very high”. Of course, it can be adapted to your business context.
• Confidence: how confident are you that this will work? if it has been implemented in the past, or if there is wide documentation about this task.
• Ease: how hard is it to implement? based on your team skills and possible technical debt, it should be measured on this variable.

Finally, the ICE Score:

ICE SCORE = Impact x Confidence x Ease

Again, the item which has the highest ICE score should be handled with higher priority than others. That said, my product backlog for the second sprint was ranked as shown in Figure 6. Then, my Kanban board has been prioritised following the ICE score.

Despite enjoying the ICE score, for more complex projects I wouldn’t recommend it. Instead, can be used robust frameworks such as RICE and BRICE Scoring models. They add other important business variables.

Figure 6— ICE Framework

By mixing the prioritisation models, we can see the sprints overview over time in Figure 7. As mentioned at the beginning, this is an ongoing project, and for this reason, the product backlog increases over time. There is always room for improvement :)

Figure 7 — Stories Overview Over Time

From the project management perspective, that was the project to develop the website. The final result can be found here and in the next week, I’ll be writing the DevOps pipeline used in this project. Hope this article can be helpful somehow for you!