DEV Community: Amila Rangana

DevLog #18 - Definition of Done

Amila Rangana — Thu, 25 Apr 2024 21:56:20 +0000

Definition of done (DoD) is a set of rules that should be satisfied when the new feature of the product is ready for deployment. These criterias touch different angles such as functional criteria, non functional criteria, technical criteria, quality criteria etc… Those will increase the quality and increase the usability of the product.

According to our project, we defined technical, quality and functional criterias to define the completeness of a new feature. Actually, with the time constraints and the team capacity, we could not consider extra criterias like non functional, integration and approval criterias. My opinion is that If we could satisfy those criterias, our product would be more solid than this because to satisfy all those criterias, the product should be improved to that extent from every aspect.

DevLog #17 - How to affect Cost of Change" and "Cost of Deciding to a project

Amila Rangana — Wed, 24 Apr 2024 21:46:31 +0000

‘Cost of Change’ and ‘Cost of Deciding’ both concepts are crucial in any kind of project management. Cost of Change refers to expenses that should be made for alterations in the middle of the project. Resources and time can be identified as direct expenses. Cost of Deciding refers to expenses for making decisions in the middle of the project.

Within the context of our project, we have to change mobile apps into web apps in the final sprint. Then we have to spend lots of time on it and waste resources and time on it. Before starting this activity we have to spend time on decision making also. Therefore we had to incur Cost of Change and Cost of Deciding within our final sprint.

In my opinion, we failed at collecting requirements from actual users of the apps and if we could collect requirements from customers correctly, could decide in prior sprints, we could eliminate these extra costs as much as we can.

DevLog #16 - Velocity charts

Amila Rangana — Tue, 23 Apr 2024 22:11:30 +0000

Velocity charts indicate completed tasks along with the sprints. Typically, Y axis shows completed tasks that are measured by story points, hours or tasks and X axis shows sprints. This represents a graphical view of the amount of work that the team has completed within the past sprints.

In our project, we used these charts to identify our team performance and get the decisions to change our way of working (Mob programming to pair programming). We could identify that if we work as mob programmers, we could not complete our sprint backlogs and then we discussed and changed it to pair programming methods based on the result of velocity charts. In my opinion, if we could not meet our expected velocity in our project with the pair programming, we could identify it with velocity charts and then we can get a decision based on that.

Finally I can reflect that if we work in a scrum team, to maintain constant velocity of work along with all the sprints, we have to generate and check these charts at the end of every sprint and need to analyze them with the team members. After that we need to identify the factors that cause the velocity reductions before taking the decisions.

DevLog #15 - Sprint Retrospective

Amila Rangana — Mon, 22 Apr 2024 21:47:11 +0000

Sprint retrospective is a crucial event that is held at the end of every Sprint, in the Scrum Agile methodology and the purpose of this meeting is identifying issues with the process, collaboration and finding solutions for those matters. After the sprint review, team mates including product owner, scrum master and the development team should get together and discuss “what went well”, “what did not go well” topics to identify issues with the process and collaboration separately. After that, the team should discuss “why it happened”, “What actions could be taken” topics to improve the process and collaboration to overcome those identified issues.

According to our project, we could use retrospective meetings to address lots of process and collaboration related matters. In the first sprint we followed the “Mob programming” method as our team collaboration method and at the end of the sprint, we could not complete our sprint backlog. Then in the sprint retrospective meeting we identified that issue and took a decision to change it to pair programming. And in the second sprint also we could not complete our sprint backlog and we identified that our estimations should be improved and we decided to use planning poker in the retrospective meeting and we could succeed in the third sprint.

According to my reflection, If we did not use the retrospective, I think we would still be struggling to identify why we could not complete our sprint backlog on time because only we focused on product changes and improvements in sprint review. I think if we can use the sprint retrospective more effectively, we can improve efficiency and can drive projects towards our goal easily.

DevLog #14 - Sprint Review Meeting

Amila Rangana — Fri, 19 Apr 2024 22:00:05 +0000

Sprint review meeting is a one of key ceremonies of the scrum Agile methodology and it helps the team to discuss and finalise the progress of the work done within the sprint. Initially, the team will demonstrate the work they have completed to the stakeholders and customers and then get the feedback from them about further suggestions, changes and improvements or clarify the reasons behind the functions which they do not have the idea to the stakeholders. After that based on the feedback and gained insight from the sprint, the product owner will adjust the product backlog.

According to our project, we have been conducting sprint review meetings for 3 sprints up to now. I think we have done a good job up to now in the review meetings and we have improved and groomed our product backlog based on the feedback we received. Based on my point of view, all stakeholders of the project need to contribute to the review meeting and should have an open discussion with the development team. As an example, in our project, we had not included login for the nation admin and our project supervisor explained to us about the usefulness of the login for admin and he explained that we can do it in a very simple way. And he asked us why we have implemented login for nation users and as the development team, we could clarify to him the reason behind it and why it was more important than our backlog items. Then we can consider it as a clarification for the stakeholder. Finally, I can express that the sprint review meeting is a very useful event in the scrum methodology based on my experiences in this project.

DevLog #14 - Activities of the Scrum Master

Amila Rangana — Thu, 18 Apr 2024 21:35:59 +0000

The main role of the Scrum master in Agile Scrum methodology is maintain the values and principles of the scrum team such as commitment, courage, focus, openness, and respect while facilitating for Sprint Planning, Daily Stand up meetings, Sprint Review meetings, and Retrospectives. On the other hand, he/she monitor the progress of the sprint by process angle while removing the any forms of obstacles.

With our project, scrum master is shaping our sprints with scrum ceremonies and scrum principles. I think scrum master need to keep close contact with all the team members and should have a understanding about their capacity, working pattern etc.. to be a successful scrum master because he/she needs to support in process related matters into their own way. As per my reading, scrum master should equipped with good communication skills, problem solving skills, analytical skills and to certain extends HRM(Human Resource Management) skills also.

DevLog #13 - Role of the Product owner

Amila Rangana — Wed, 17 Apr 2024 21:53:24 +0000

Product owner plays a key role in the team that follows Agile Scrum methodology and has more responsibilities to handle in the team. Mainly, product owner should represent the stakeholders to communicate the requirements to the team and should ensure that team delivers the value to the customer, acting role like 'Man in the middle' between stakeholders an the development team. Therefore, product owner is the person who maintains the product backlog adding new items, removing useless items, refine existing items according the priorities.

In the context of our project, I am the product owner and I could practise above mentioned tasks with the help of my team members. As my point of view, product owner should be a good listener, analytical thinker and good team player as well as having previous experience is added advantage because he needs to communicate and balance both stakeholders and development team to deliver correct value to the customer. If the product owner understands a requirement wrong way or sets the priorities wrong way, it will be added to the product backlog same way and development team develops it the same wrong way and will be delivered it to the customer without proper value.

Finally, I needed to emphasise that we need to more careful while selecting a team member as a product owner.

DevLog #12 - Kanban

Amila Rangana — Tue, 16 Apr 2024 21:53:52 +0000

Kanban is a Agile methodology that can visualise work flow in a column separated board. Normally, the Kanban board contains 3 columns such as "Todo", "In progress" and "Completed" to visualise the work flow and cards to represent the tasks of the project. But if you need you can enhance the no of columns as your requirement such as "In QA", "In code review", etc..
It is very useful tool when it comes to handling complex projects because it shows the current status of every tasks to the whole team and it improves the transparency of the project among the team.

In our Agile based project, we have configured a commercial tool called "Jira" to manage our project and it consist with a Kanban board with three columns to manage and visualise work flow.

As my point of view, it will save the lots of status reviewing time of our team mates. Further, team can identify if there is a bottleneck in the workflow analysing the in progress time of tasks. I can reflect that using Kanban board is more easier and useful than using a list of task with textual status.

DevLog #11 - Sprint Backlog

Amila Rangana — Mon, 15 Apr 2024 21:57:57 +0000

In an software development project that leads by Agile scrum methodology, sprint backlog is a subset of the product backlog that contains user stories, tasks and other development related activities to be completed within the sprint. In the sprint plan meeting, development team discuss and select relevant tasks and user stories for the sprint backlog based on their priority, effort to be completed and capacity of the sprint. Though in product backlog consists of high-level user stories, sprint backlog contains smaller and more manageable tasks.

It comes to our Agile based project, we have selected the most prioritised tasks and user stories from our product backlog based on the value that we can deliver to the customer in the end of the sprint. While selecting the tasks we considered about the effort we have to spend on it to complete and capacity of our sprint also. Though there was a high priority tasks available to be completed, we have to postponed it cause capacity of our sprint was not enough.

I think we can list down the tasks based on the priority order (most prioritised task on the top) in the product backlog and take the top few tasks which fits to our next sprint size. I think if we select a task which takes more time than our sprint can cater and try to complete with extra time allocation, it will reduce the quality of the feature and it will break the work life balance of the developers also. Then we have to be careful while selecting the tasks for sprints.

DevLog #10 - Product Backlog

Amila Rangana — Fri, 12 Apr 2024 21:57:47 +0000

Product backlog plays a main role in Agile practice that enables the clear representation about what should be developed to deliver value to the customer. Product backlog should be a dynamic entity that always open to updates and refinements with based on feedbacks of customers, changes in business requirements, new market trends and learnings through developments.

According to our project, we have been maintaining our backlog through out the project development period up to now as discussed above. Based on the actual customer requirements, we added new user stories into the backlog. From leaning through our developments, we removed some details showing stories since our current development has catered that feature already and we could deprioritised some user stories. Normally we expected to have login screen for the user in the first app opening and we changed it to have a login while applying for the shift based on new market trends.

As I explained above I think we can maintain product backlog though out the project adding, refining, removing and prioritising backlog items. It will help to deliver the best value to the customer end of the project.

DevLog #9 - Panning Poker for Scrum

Amila Rangana — Thu, 11 Apr 2024 21:54:08 +0000

Estimating the stories is a key practice in Scrum Agile methodology. It helps team to take more measurable view about the project and it exposes the understanding towards severity, uncertainty and complexity of the story also.

Before starting the project, team should sit together and need to estimate backlog stories to put into sprint backlog. If there are people with different experience levels, it will be more challenging to estimate stories since they will identify story size in different ways. To solve this issue, there is a small technique like a game called "Planning poker" and according to my opinion it will helps team members to have common estimation that is suitable for all the team members.
And the other hand, it will improve the shared understanding of the user story among the team members because they have to discuss about the user story deeper.

In out project scenario, we had a issue with estimating our stories in last sprint with different experience level people and we got delayed some of our tasks than we expected. Then we discussed and came up with a idea to experiment with the "Planning poker" and test it's productivity.

DevLog #8 - Code review in XP

Amila Rangana — Wed, 10 Apr 2024 22:29:11 +0000

In Extreme programming Agile methodology, code review is a main practice which improve the code quality and reduce the defect count. In a agile team, there are several ways that can review codes and I will reflect my opinion on each.

Peer review: The code will be reviewed by the team member in the same level or with same experience. In this level, it is expected to share the knowledge as well as reduce issues in the code. And since the coder and the reviewer are in the same team, it leads to have a conversation about the coding techniques that have been implemented and it will help to share knowledge.
On the other hand, experienced team member can review the code that written by inexperienced member. It will mainly help to find issues and defects in the code. Then reviewer can advice the coder to improve the code quality.

In our project, we can implement both the ways since we have 3 inexperienced members and one experienced member. Among inexperienced members, we can arrange peer reviews and experienced member can review the code after that. Then we can share the knowledge and reduce the defects count also.