- What is Agile and what are user stories?
Agile refers to a software development methodology that provides more efficient ways of handling and managing software development projects as compared to traditional methods such as the waterfall development methodology. Agile development allows for the evolution of requirements and problem solutions through the collaboration of cross-functional teams. The methodology promotes evolutionary development, adaptive planning, continuous improvement, early project delivery, and promotes rapid response to change. Agile has some unique characteristics and emphasizes more on interactions than development processes and tools. The methodology also places more focus on delivering working software as opposed to comprehensive documentation. Other areas that Agile emphasizes on are customer collaboration over contract negotiations, as well as responding to changes instead of sticking to rigid plans (Hamed & Abushama, 2013, p.161).
Why Agile?
Agile has become a popular software development methodology due to its applicability in a wide array of projects. Some of the reasons why it is popular is because it promotes teamwork and allows for iterative development. Agile emphasizes the importance of teamwork and uses the scrum framework where ten to fifteen minute daily stand-up meetings are held. These meetings, also known as scrums, are frequently held to allow team member communication regarding project progress, and for easier decision making. Other traditional methodologies such as the waterfall methodology place more emphasis on project requirements, independence and documentation.
In the waterfall methodology, all tasks are planned ahead and predetermined since the development team has to create an entire project, test it and deliver it all at once. The development process is time-consuming since it involves much testing. However, Agile takes on a different approach, and instead of developing the entire project in a set duration, it divides the project workload into sub-tasks known as sprints. Each sprint takes about two and four weeks to be completed. The short development cycles thus help make the project more manageable thus making the Agile methodology more flexible to changes made by clients. It also requires less planning when compared to traditional methodologies such as waterfall.
What are User Stories?
User stories are used in Agile development to provide brief descriptions about project features from the perspective of end users. User stories define what should be done to fulfill project requirements, and instead of spending time writing comprehensive documentation, user stories state key project features using just one or a couple of sentences. The basic structure of a user story is usually: As a <role>, I want <feature> so that <benefits>. Examples of user stories used in our project include:
- As an owner, I want to display store location, working hours, and contact information so that customers can easily contact me or find my store location.
- As an owner, I want to have a QR code for my Facebook page so that customers can easily access my Facebook page.
The Agile Process:
Our team project involves designing a Facebook application for a hair salon known as Beauty PT. When the project began, the team identified all user stories such as QR codes, location, nail, hair and service tabs. The estimated workload for each user story was then determined and sub-divided into sprints.
At the end of each sprint, a working application prototype is delivered as well as charts and graphs to visualize all that has been done in each sprint. One of the most useful charts is the burn down chart that helps measure the remaining amount of work so that it is easier to monitor work progress, and keep the project on track. Based on the feedback realized, team members can revisit the plan and make the necessary alterations such as QR code redesigning and adding Google Map features to the location tab.
What projects are good for Agile?
The Agile methodology is applicable to various software testing and development projects due to its teamwork approach. An empirical study conducted at Microsoft by Begel and Nagappan (2007) to explore the usage of Agile and developer perceptions about it revealed that developers appreciated the benefits of having better communication within teams and improved flexibility. However, there were concerns about the sizes of teams and the efficiency of scrum meetings. In this case, it was noted that Agile is not a perfect approach for all projects.
Agile is particularly suitable for projects involving small teams with relatively short development cycles, and is not suitable for projects that are under maintenance process or those that involve very few changes (Ambler & Holitza, 2012).
- Agile teams and backlogs. What are they for and why are they important?
As earlier stated, Agile development is suitable for team projects. A standard Agile team consists of the product owner, the scrum master, developers, testers and customers. The product owner guides the team through the project, helps in developing a list of user stories, makes changes on the desired project features, and re-prioritizes the task lists.
Scrum masters are responsible for setting up and leading the short scrum meetings, ensures each member’s contribution, and monitors the burn-down chart to ensure the project is completed in time in order to meet the deadlines set. Developers communicate with team members to get all requirements and are also responsible for implementing all the required features.
Testers and customers are important groups when it comes to collection of feedback. The testers implement various project testing practices and tools to ensure the application works as required and that product quality is ensured. Customers provide responses with useful feedback such as user experience and how to improve user interface design.
Each individual in the Agile team has a specific role and/or specialty. These individuals are also different in terms of backgrounds, knowledge and experiences. Since Agile teams emphasize more on teamwork collaboration, team members share knowledge and cooperate with each other to finish projects on time. As a result, Agile teams are important since their collaborative nature ensures timely project completion.
Backlogs in Agile development.
A product backlog as used in Agile development refers to a collection of stories to be worked on by the sprint teams at some point in the future (Gregorio, 2012, p. 2). Since the backlog is a list of user stories, it describes in entirety the desired functionality of the product under development in some priority order. The Figure 1 below shows the priorities of items. High priority items are denoted as “worked on soon” items and are described in more detail compared to items of low priority. The product backlog thus contains a list of different items and includes their features, flaws, knowledge acquisition work, and technical work thus making it easy for team members to easily access the backlog and product information (Rubin, 2012).
Figure 1: Example of a product backlog
Importance of the product backlog:
The product backlog is important to Agile teams since it aids team members in visualizing and understanding the desired product features that need to be developed, and also inform the team on any changes made. More importantly, the maintenance and overall quality of the product backlog are crucial for the successful completion of scrum projects (Mahnic & Rozanc, 2012).
In a survey conducted among student and professional developers on the success factors of scrum-based software projects, the professional developers rated the maintenance of sprint backlogs as very important in contributing to scrum project success (Mahnic & Rozanc, 2012).
The use of backlog in our team:
In our team, each member has a crucial role. The scrum master holds meetings every Saturday to discuss what needs to be done. There is a note taker who writes down notes on product features and issues. All these notes are put in the backlog to ensure every team member knows what needs to be done throughout the project sprints. After each meeting, we work on what was discussed in the backlog such as the Facebook tab and QR code design. At the end of the sprint, we combine everything and come up with a working prototype for the client.
- What is Agile Sprint Retrospective?
The Agile sprint retrospective is a meeting held after the sprint review meeting. The meeting offers an opportunity for the Agile team to reflect on the success of the previous sprint and the areas that need improvement so as to ensure continuous progress through the entire sprint project (Drury, Conboy and Power, 2011). The team members who usually participate in the Agile Retrospective meeting usually include the product owner, scrum master, developers and testers.
The meeting is facilitated by the scrum master who prepares team activities. During the meeting, each member contributes by giving their opinion and feedback. The scrum master also reviews the sprint backlog and invites team members to discuss the tasks assigned to them, and the work is done in the sprint.
In order to collect feedback effectively, the scrum master can also conduct various activities to facilitate discussion and reflection among the team. For example, Maham (2008) conducted an activity he called “Pump It or Dump It” to aid the team in reviewing improvements and make decisions on whether the practice should be continued or dropped. Team members were asked to write improvements on cards that were then posted on a timeline. Red cards were used for practices that needed to be dropped while green cards were used for practices that needed to be continued. Additionally, team members assigned green dots for positive events and red dots for negative events.
In retrospect, the Agile Sprint perspective helps the team make decisions on improvements in future sprints. According to data collected by a group of Agile practitioners regarding Agile team decision making, it was found that the sprint retrospective was very helpful to the team in decision making to improve the team’s agile processes (Drury, Conboy and Power, 2011). These decisions can either be tactical or strategic. Tactical decisions are based on the creation of new practices, improvements and new ideas to be tried out in the next sprint. Strategic decisions focus on the success factors and identifying possible causes of failure.
Decision making is important as it helps the team build a better product after the conclusion of each sprint. As a team in our retrospective meeting discussed their experiences and reviewed the things they had learned, the note taker took notes. However, the team usually comes up with suggestions on improving productivity and addition of new features. When these suggestions come up, it is the duty of the scrum master to make adjustments in the project backlog and re-prioritize actions as necessary. The goal of re-prioritizing is to ensure all team members are reminded of what requires to be done to improve the next sprint.
In the Beauty PT project, some my teammates and I had previous experience in creating Facebook applications using HTML5. However, in the first few meetings, the team did not communicate very well since we did not know each other too well, and this slowed down the first sprint significantly. Fortunately during the sprint retrospective, the team reflected on the communication shortcomings seen in the previous sprint and made improvements for the next sprint. As a result, we were able to effectively design and deliver three Facebook tabs and a QR code in the third sprint. In this sense, it can be concluded that the retrospective meeting was an essential part of our project.
- Agile tasks lists, what does “done” mean in Agile?
During each sprint, there is a list of user stories that needs to be addressed by the team. In order to implement the user stories, the requirements are first broken down into tasks and the team members determine the tasks required for each story. Agile task lists, therefore, include a list of activities (tasks) that need to be completed to ensure the completion of each user story. When the team members come up with the tasks necessary for the story, they also estimate the duration of each task. Each team member signs up for a particular task(s) then all of them estimate the hours needed for the completion of each task. The estimation times for each task range from one to sixteen work hours. Individual tasks that require more than sixteen hours to be completed are considered too big hence they are further divided into smaller tasks.
The contents of an Agile task list usually include a description of the user story, the required tasks, the team members responsible for each tasks, the estimated completion time for each task, the estimated complexity of each task, the actual time needed to complete the task and customer priorities. All the tasks in the list are usually represented in a simple spreadsheet (Reichlmayr, 2003).
The Agile task list helps in planning and tracking project progress since it informs each team member of the tasks they are responsible for, and the progress of their assigned tasks. The task list is also very effective in improving member understanding of user story implementation, the direction of future developments, and expected problems and solutions (Folwer, 2013). The Figure 2 below shows an example of Agile tasks list.
Figure 2: Example of an Agile task list
What is “done” mean in Agile?
In software development, when a project is “done”, it usually means project implementation has been completed successfully. In quality assurance processes, “done” means that a project feature has been thoroughly tested by the testers. In Agile development, “done” means that a particular product feature has successfully been built and is ready for shipping. In other words, by the end of each sprint, the Agile team needs to deliver a working prototype.
When a team delivers a prototype that works 100 percent, they are only “done” if they also ensure that all the desired requirements and features have been incorporated before moving onto the next sprint.
In the first sprint of the Beauty PT project, I was responsible for implementing the location tab. I also tested the tab thoroughly on my Facebook account and personal server to ensure it was working as desired. In terms of software development, my part as a software developer is considered “done”. However, from an Agile development perspective, my part is not yet done. The issue arose due to the requirement of all Facebook applications to have a valid SSL certificate. However on trying to deploy the application in the client server, it was found that the client domain did not have an SSL certificate installed. Eventually, extra time had to be spent on finding alternative solutions. However, if the Agile approach had been used, the problem could have been avoided early enough.
References:
Ambler, S. W. & Holitza, M. (2012). IBM, Agile for dummies (IBM Limited ed.) Hoboken, NJ: John Wiley & Sons, Inc.
Begel, A., & Nagappan, N. (2007). Usage and perceptions of agile software development in an industrial context: An exploratory study. In Empirical Software Engineering and Measurement, 2007. First International Symposium on, 255-264. doi: 10.1109/ESEM.2007.12 Retrieved from: http://research.microsoft.com/apps/pubs/default.aspx?id=56015
Drury, M., Conboy, K., & Power, K. (2011, August). Decision making in agile development: A focus group study of decisions and obstacles. In Agile Conference (AGILE), 2011 (pp. 39-47). IEEE. Retrieved from: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=600550
Figure 1. A Proven, Publicly Available Framework for applying Lean Agile practices at enterprise scale [Electronic image]. (2014). Retrieved September 21, 2014, from: http://safe30.com
Fowler, M. (2013). How do you estimate on an Agile project? Chicago, IL: ThoughtWorks, Inc. Retrieved from: http://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf
Gregorio, D. D. (2012, March). How the Business Analyst supports and encourages collaboration on agile projects. In Systems Conference (SysCon), 2012 IEEE International (pp. 1-4). IEEE. Retrieved from: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6189437
Hamed, A. M. M., & Abushama, H. (2013). Popular agile approaches in software development: Review and analysis. Computing, Electrical and Electronics Engineering (ICCEEE), 2013 International Conference on, 160-166. doi:10.1109/ICCEEE.2013.6633925 Retrieved from: http://ieeexplore.ieee.org/xpl/abstractAuthors.jsp?arnumber=6633925
Maham, M. (2008, August). Planning and facilitating release retrospectives. In Agile, 2008. AGILE’08. Conference (pp. 176-180). IEEE. Retrieved from: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4599472
Mahnic, V., & Rozanc, I. (2012, May). Students’ perceptions of Scrum practices. In MIPRO, 2012 Proceedings of the 35th International Convention (pp. 1178-1183). IEEE. Retrieved from: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=62408222
Reichlmayr, T. (2003, November). The agile approach in an undergraduate software engineering course project. In Frontiers in Education, 2003. FIE 2003 33rd Annual (Vol. 3, pp. S2C-13). IEEE. Retrieved from: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1265946
Rubin, K.S. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process (1st ed.) Indianapolis, IN: Pearson Education, Informit. Retrieved from: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4599472
Ruhnow, A. (2007, August). Consciously evolving an agile team. In Agile Conference (AGILE), 2007 (pp. 130-135). IEEE. Retrieved from: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4293585
