For week 10’s activities and materials we returned to Agile Practice and explored the Agile manifesto, as well as looking deeper into the methods of envisioning and effort estimation.
Agile practice has its origins with the software development industry, where developers were unable to meet the needs of their customers through traditional linear planning and development means. For example; projects would typically take a long time to complete and the original goal may have changed or simply been superseded during the project’s development lifecycle.
Developing agile practice would allow the same teams to deliver the product in a more dynamic and flexible way – i.e. lots of incremental improvements done regularly through “sprints”.
This allows for feedback to be given more often from the client/users and ensure continuous delivery and improvements, allowing users to cope with change and allows developers to change and improve things without alienating the user base.
Workfront.com describes the agile manifesto as;
“… a declaration of a unifying philosophy for frameworks like Scrum, Extreme Programming, and Feature-Driven Development (FDD). The Agile Manifesto greatly departed from the waterfall-style project management approaches that were widely in use prior to that time…
The Agile Manifesto states that it values:
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
Workfront.com also explains that:
Agile solutions come about as self-organizing, cross-functional Agile teams employ the appropriate practices for their context. But that doesn’t mean they do without managers. Managers are still needed to:
· Create an environment that allows for team success
· Make sure team members have the appropriate skill sets
· Provide guidance when teams can’t resolve issues for themselves
· Clear roadblocks and secure outside resources as needed
Using the manifesto as guide teams are empowered to develop their own agile methods and techniques and have ownership of these methods and tools using different types of agile methods such as Scrum.
A scrum framework typically consists of:
· Product Backlog
· Sprint Backlog
· Sprint
· Sprint review / additional envisioning
· product increment
The product backlog consists of all the things that need to be done to complete the whole project. To be effective, a product backlog should break down each of the items on the list into steps that helps the development team and must include a timeframe.
The sprint backlog works similarly to the product backlog and is developed from the product backlog – but only contains one item that can be completed during each sprint.
In the book, Essential Scrum, the term ‘envisioning’ is used to describe the process of “capturing the essence of a potential product” by creating a rough plan for the creation of that product (Rubin 2013).
The envisioning process typically follows the results of the output from an ideation phase or changes made from a previous sprint and links into the length of time accounted for and completion date for the product, as well as budgeting and resources needed.
Envisioning (which is also known as product level planning) is the aim of capturing the essence of the product and is a fast, efficient process that allows developers to get to the prototyping phase sooner. It’s important that this is a quick process, as priorities within the product can change such as; funding and technology improvements etc.
However, projects using this method still need to be effectively and formally defined as clients are unlikely to give funding otherwise.
Rubin also suggests that the envisioning process should contain considerations for: features, high-level solutions and costs explaining that it’s important not to spend too long envisioning – do not worry about vagueness, but concentrate of the higher level vision, aiming to get closer to product perfection by completing continuous cycles of planning, implementation, testing and evaluation.
The initial envisioning process should produce just enough information to inform the first release and be high value, with minimal cost. This allows the team to reflect on whether they are heading in the right direction or make changes.
Output from the envisioning process should have the following:
· Target customer
· Key benefits
· Purpose of the project
· Information about roles and responsibilities (this should be included, even if solo working)
Once the vision is complete, you need to move onto the user story. The user story takes the form of a statement that is used to explain the product features and form part of the Scrum artefacts Product Backlog and Sprint Backlog and deals with higher level details on a more granular level.
As well as user stories, teams will need to complete “epics” , which are usually one large piece of the products functionality – normally too large to be completed into one sprint. Product functionality is usually dissected into epics so that the project time and budget can be estimated.
Another aspect of the Scrum method is estimation.
According to Woodward et al, “a core principle of Scrum is that the team members responsible for delivering the work should estimate it” (2010).
Estimating the time a task will take can be challenging and easy to miscalculate, fortunately there are a variety of Agile techniques that can be applied and practised to help with this.
To be able to accurately estimate, a Product Backlog full of epics from the envisioning process is needed to answer the following questions:
· How many features will be completed?
· When will they be done?
· How much will it cost?
The epics need to be broken down into smaller manageable stories
Once done, the estimation process can begin. Estimation is all about effort and requires the people that will complete the work to take part. Rubin’s three principles propose that:
· Estimates are not commitments – clarify estimates are just that and subject to change
· Focus on accuracy, not precision (accurate measurements = correct values, precise measurements = consistent values)
· Use relative vs absolute sizes
Story points
Story points can be used to measure the size of a product backlog item (PBI), to estimate a story point you need to consider three factors:
· The amount of work needed to carry out the task
· How much risk and uncertainty are involved?
· The complexity of the task
Ideal Days
Ideal days are basically the days where you have everything you need and nothing goes wrong – very rare indeed! Estimating in ideal days involves looking a PBI and guessing the amount of ideal days it would take to complete. These can be easily misunderstood and interpreted as “average” days, so are best used internally.
Team Velocity
Team Velocity is where the work carried out from a previous sprint and is added to story points or ideal days to calculate velocity and can be used to forecast an overall timeframe for project and estimate cost. Velocity can also be used to evaluate and improve use of scrum to deliver better service.
This week's challenge activity gave a good insight into what is needed to complete story points and how to create personas and can be found here.
Week 10’s challenge activity and materials have been really useful, as it has allowed me to refresh and improve upon my newly found knowledge of Agile and also look at the Scrum method - which I chose to not research and use in earlier weekly activities.
I am now looking forward to employing the envisioning process with my artefact’s development in the next module and am excited to see what result it will bring! References:
www.workfront.com. (n.d.). What is the Agile Manifesto? 12 Principles & 4 Values | Workfront. [online] Available at: https://www.workfront.com/project-management/methodologies/agile/agile-manifesto. [Accessed: 18 December 2020].
Agilemanifesto.org. (2019). Principles behind the Agile Manifesto. [online] Available at: http://agilemanifesto.org/principles.html. [Accessed: 18 December 2020].
Rubin, KS. (2013) Essential Scrum. Upper Saddle River, Munich [u.a.]: Addison-Wesley.
Waldock, B. (2015) Being Agile in Business: Discover faster, smarter, leaner ways to work. FT Press.
Woodward, E., Surdek, S. and Ganis, M. (2010). A Practical Guide to Distributed Scrum. Upper Saddle River, NJ [u.a.]: IBM Press.
Comments