5

Project

Name

Institutional Affiliation

Project

Part One: User Story Points and Team Velocity

User stories can be described as popular or significant models for representing requirements, usually with the utilization of simple templates. The adoption of user stories is increasingly becoming important, especially within the context of agile project management and development (Patton & Economy, 2014). The increasing popularity of user stories legitimates the view that software developers consider them efficacious for capturing and representing the right software requirements. User stories also provide informal, natural language descriptions for one or more features of a project or software system. In this respect, a user story can serve as a tool that is utilized in agile project development to capture descriptions of project features from an und-user’s perspective. Therefore, user stories often describe the kind of user, what they desire in a product, and the reasons.

Projects may require additional iterations for them to be completed within the same team pace, a concept referred to as team velocity. As soon as each project development component is completed, there is need to consider the number of points that are delivered and adjust the team velocity accordingly in order to refine the estimates to completion on the basis of the number of remaining points on the work item list (Patton & Economy, 2014). People often need to correlate story points with hours based on motivation to forecast and plan Team velocity is estimated in story points that are accepted per iteration and should be based on historic team performance to incorporate the most recent iterations. In order to determine how much time will be taken to complete the story points in product backlog, there is need to multiply the sprint length by the number of remaining sprints (Layton & Ostermiller, 2017). To determine the number of sprints, there is need to divide the number of story points remaining in the product backlog by the team velocity.

Part Two: Scrum Project Part 4

Summary of Relative Level of Effort

The process of completing the project required significant levels of effort for each item in the backlog and the team velocity. In order to address the typical product development planning issues such as the efforts needed, time taken, and the costs incurred, the scrum team estimated the size of development and the measures of their respective velocity, which is the rate at which they can get the work done. Using this data, it was easy to derive the likely product development period and the corresponding costs through division of the estimated size of sets of features by the team’s velocity. The estimate s for planning are commonly made at three different levels of details, depending on whether they are working in the project portfolio backlog, the product backlog, as well as the sprint backlog. As soon as a product has been approved for development, its product backlog items get more detailed. Such product backlog estimates expressed as story points or ideal days. These forms of estimation essentially take place in product backlog grooming meetings, the first of which often coincides with initial release planning. Furthermore, the estimates of the tasks in the sprint backlog were determined by typically getting sized in ideal hours. As such, if the team estimates that can take five hours to complete, it does not imply that it may take five elapsed hours. To the contrary, it may take an individual various days or many people working together less than half a day.

Approach to Completing the Assignment

The process of completing this assignment was not an easy task. It required making informed decisions in every stage of the project life cycle. This is because the project required using the agile approach. Many traditional projects that use the traditional waterfall model often entail lengthy requirements gathering efforts. This problem results in complex documentation processes and project plans that have estimated hours and costs. However, my project entailed utilization of agile development methodologies that provided me with key benefits of offering the capacity to speedily evaluate the length of time that it takes to complete a project and the potential costs that may be incurred. At some point, I needed to estimate story points. In order to achieve this objective, unit less numbers were utilized to support the process of estimating user stories through categorizing requirements on the basis of equivalent difficulties. This process involved creating product backlog, determination of the scale, estimation of the backlog, as well as establishing of release planning estimates. I found that the product backlog is where all the requirements are kept within an agile project in the form of user stories. Tough decisions had to be made, including making user stories the epics. Moreover I ensured that the user stories contained high-level features of the system.

Reflection and Lessons Learned

This project has provided me with more insights into managing projects using agile methodologies and frameworks. For instance, I have mastered the art of monitoring and adjusting velocity. As soon as a project kicks off, the scrum team should begin with monitoring its velocity. Indeed, agile project management is founded on the concept of team velocity, which is measured in two terms: story points and task labor hours. To this end, scrum developers often derive a team’s story point velocity from a tally of user stories that are accepted and rejected during the user demo. In light o the above, teams can utilize their story point velocity to develop a current estimate of the number of limited, but equally significant, applications (Layton & Ostermiller, 2017). This velocity can be employed only to establish the capacity number for the next sprint. This, in turn, can help to determine which stories can be committed to for the next iterations.

I have also learned to utilize velocity to determine long-range costs. Once the scrum velocity has been determined, it can be easier to calculate the costs for the remainder of the project. The project costs can be determined by multiplying the cost per sprint by the number of sprints that the scrum requires to complete the product backlog. For instance, in case the scrum team cost is $20000 per sprint, and only 40 sprints are remaining, the remaining costs for the project can be $800000. In some cases, the costs can be high and may require lowering. I have learned that costs can be reduced by increasing velocity (Layton & Ostermiller, 2017). The costs can also be lowered by reducing time. In particular, project costs may be lowered by not completing the lower-priority requirements, thereby reducing the number of sprints that are required. On agile projects, since completed functionalities are delivered in each sprint, the project stakeholders and team members can make informed decisions to end a project when the costs if future development is higher than the value of that specific future development.

Finally, I have gained insights into the process of determining the iterations that are needed to complete a project. The completion of a project is often undertaken in fixed chunks of time that is commonly referred to as iterations. In order to start an iteration, there is need to pick the list of tasks that is perceived to be completed within a specific iteration period (Cline, 2015). Furthermore, before assigning tasks to iterations, there is need to determine the length of time that the iterations may take. I have also observed that there may be no need to consider weekends and resting days such as holidays when completing the iterations.

References

Cline, A. (2015). Agile development in the real world. New York, NY: Apress.

Layton, M. C., & Ostermiller, S. J. (2017). Agile project management for dummies. New Jersey,

NY: John Wiley & Sons.

Patton, J., & Economy, P. (2014). User story mapping: discover the whole story, build the right

product. New York: " O'Reilly Media, Inc.".