Search

How Not To Be Agile – 3. An Effective Product Backlog

IntroductionHello and welcome to this, the third article in the series ‘How Not to be Agile’.‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits when an organisation, or a part of it, embark on an Agile Transformation.Last time, I discussed the potential pitfalls of not having a suitable Business Case for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.This time, I will cover some of the misunderstandings and malpractices that I have come across with respect to the next major item to consider in any Agile framework, the requirements.  The most often used term for the requirements list is the Product Backlog from Scrum; I will use this and other Scrum terminology in this article but you can use whatever names you like; it is the content and management of the requirements list that is important.I will start with a description of the Product Backlog process and then give examples of what has and could go wrong if not follows the Product Backlog tips.The Definition of Scrum Product Backlog Having achieved an agreed Vision and Objectives and decided that the Business Case for the product development is viable, the business stakeholders and development team need to discover a list of ‘business requirements’, at the same level of detail, so that the development team can develop the product in a series of short development timeboxes.These ‘requirements’ become Product Backlog Items (PBI). What is a ‘Requirement’?Functional Requirements:There are 3 commonly used ‘structures’ used to express ‘Agile functional requirements’:Elementary Business Processes (EBP) – the names of EBP, usually extracted from the results of the Business Process Modelling exercise concerned with the area of the business that the product is for; for example:                                                                                              ‘Capture Customer Details’Use Cases – from the Unified Modelling Language (UML).  Only the names of the Use Cases, again, usually extracted from the results of Business Process Modelling exercise and the example is the same as for the EBP aboveUser Stories – a technique from eXtreme Programming which states the user of a business process, the name of the process and why the  process is needed; for example:                                                                                                    ‘As a sales person                                                                                  I need to Capture the Customer Details                                                                                        So that payment can be taken’For all the 3 ‘requirements’ types, it is only the names of the business process that are needed (with the addition of the other 2 clauses in User Stories); there should be no lower level details in the PBI.The level of detail for all of the above can be summarised as:                                            ‘The name of one job, being performed by one person, at one time’Non-Functional ‘Requirements’:In addition to the Functional Requirements, the ‘What’, the business will also express the needs of ‘How’ the product will perform such as:All screens must refresh within 5 secondsThe system must be available 24/7/365The system must conform to the company marketing graphic languageand so on and so forth.These Non-Functional ‘requirements’ can be added to the Product Backlog in a separate section from the Functional Requirements or in a separate ‘document’.What A PBI Is NotThere was a fashion, that still exists in some places, to have ‘Technical User Stories’; ‘User Stories’ those name technical activities that need to be done; for example:As a database designer                                                                         I need to create data access scripts                                                     So that the product can store and retrieve the data that it needs to useSuch User Stories would just be stating elements of a team member’s work and do not add anything to the understanding of the business needs which the Product Backlog is meant to represent.It is my strong recommendation that so-called ‘Technical User Stories’ are NOT used because the Product Backlog becomes large, unwieldy, almost impossible to order by business value and prioritisation; the estimated effort for these technical needs are included in the estimation of the ‘business’ PBI; more of which later.It is true that there may be a for some activities  to set-up the technical environment before the development team can start developing the product, some of which are out of the control of the development team; these activities should take place in parallel with creating the initial Product Backlog.Creating a Product BacklogOrdering the Product BacklogThe whole point of Agile is to deliver a product incrementally so that the business can accrue the best value in the shortest possible time.It, therefore, follows that the product needs to be developed by developing the PBI in the business value order; the highest business value PBI first.Therefore, the PBI needs to be ordered by business value. I will not go into the techniques for ordering PBI, they are well documented elsewhere but I will give an example, later, of what happened when one team did not use Product Backlog ordering.Estimating the PBIWe create the initial Product Backlog just after agreeing on the Vision and Objectives and ensuring development viability via the Business Case but before development begins; it needs to be estimated in some way to determine how long it may take to develop the product and consequently how much it may cost to develop.It is a tenet of all Agile frameworks that only the development team is allowed to estimate the PBI.  Once done, these estimates will ‘inform’ the Business Case and analysis can be made to see if the original ‘high-level’ estimates in the initial Business Case are of the same order; a decision can be made as to whether the development is still viable.Types of PBI estimatingThere are 2 generally used types of PBI estimating:1. Absolute Estimating:  Whereby each PBI is estimated by how much time it would take go from just its name to ‘potentially shippable’ functionality.  Of course, the tasks include analysis, design, construction and testing and what normally happens is that each ‘skill’ will estimate the time it would take for their part in the process and the times summed to get the overall estimate.2. Relative Estimating:  Whereby the team chooses the PBI which is likely to be ‘the smallest’.“The smallest in what respect?”  you ask.  The ‘smallest’ does not directly consider time; the PBI criteria that are considered are size and complexity.However, opinions of size and complexity will vary amongst all team members depending on their skill and experience; what may seem ‘simple’ to an experienced developer may seem complex to the less experienced person.  Similarly, although the analysis and construction may seem simple, the testing may be complex.For these reasons, it is highly recommended that Relative Estimating is done using ‘Planning Poker’ which is well described elsewhere (see ‘Planning Poker: An Agile Estimating and Planning Technique’); suffice to say here, that once the team have decided which is the ‘smallest’ PBI, they give it a ‘Story Point’ of 1 and all other PBI are estimated with respect to their individual relative size and complexity compared to the ‘smallest’.So which estimating technique to use?1. Absolute Estimating can take a long time; it is akin to the traditional way of estimating for the Project Plan.  Also, it has been established that, generally, we are not very good at estimating in time; the larger the thing we are trying to estimate, the worse our estimates get.  However, the technique is familiar to most people and does not require a change of mindset to produce estimates.2. Relative Estimating requires a totally different mindset amongst the development team members because, initially, not only are they using unfamiliar criteria to estimate the PBI but also, they are estimating in collaboration with other team members with different skill sets and experience.Despite there being ample evidence that Relative Estimating takes less time overall and allows the stakeholders and development team to focus on business benefit being delivered, because of the ‘difficulties’ of introducing Relative Estimating, many teams revert to time estimation and tracking time.  Also, as we will see in one of the Case Studies below, an organisation’s choice of requirements management tool can make the use of Relative Estimating seem a waste of time for team members.Another Potential Problem with Relative EstimatingSo, having carried out ‘Planning Poker’, the development team now know the total number of ‘Story Points’ that the development represents; not much good to the business stakeholders who want to know how long it is going to take and how much it is going to cost.On completion of the initial Product Backlog and before development begins, we need to ‘translate’ this total ‘Story Points’ into time.An Agile Team’s progress is measured by the number of ‘Story Points’ that they deliver in one Sprint; known as the team’s ‘Velocity’.So we need a knowledge of the team’s Velocity in order to establish an estimate of how long the development is likely to take; for example, if the total number of ‘Story Points’ is 200 and the team’s velocity for a 2-week Sprints is 10, then the estimated time to complete all the PBI is:         200 ‘Story Points’ / 10 ‘Story Points per Sprint  x 2 (the number of weeks per Sprint) = 40 weeksHowever, at the start of an Agile transition, we do not know what the team’s Velocity is or will be.  There are 2 methods to determine what the Velocity may be:1. The team takes one of the ‘smallest’ PBI (with a Story Point of 1) and does a traditional break down to the tasks involved and estimate those tasks in time;  1 ‘Story Point’ is equivalent to the time represented by the sum of the times estimated for all the tasksThe team’s Velocity may be estimated by:                                      ‘The number of working days in the Sprint / the estimated days for 1 Story Point’For example, if the ‘time estimate’ for a PBI of 1 ‘Story Point’  is 1 day:                                             10 working days in 2-week Sprint / 1 day = Velocity of 10This velocity can then be used in the formula above to determine the estimate for the potential total time for the development.2. The development team is allowed to start development for 2 or 3 Sprints taking PBI from the top of the Product Backlog.  At the end of the ‘experiment’ period, the total number of ‘Story Points’ for the completed PBI divided by the number of Sprints completed becomes the Velocity to use in the formula above to determine the estimate for the potential total time for the development.The potential problem with this method is that management have to release funds for this experimental period without knowing the values to feed into the Business Case to determine whether the product development is viable before development begins.Once teams have completed 1 product development, we recommend that the team members are kept together for other product developments even though the business area or technology may be different.  Having a team that works well together is more important than creating teams in an ad-hoc manner.  A team’s Velocity varies insignificantly over different product developments and so can be used directly in the formula above to determine the estimate for the potential total time for the development.\Scoping the Product BacklogGenerally, Agile product developments have strict deadlines so that the major benefits can be accrued; benefits such as competitive advantage, meeting marketing needs, meeting customer expectations or complying with regulations.Also, Agile teams comprise all the skills necessary to take the PBI from ‘names’ to a potentially shippable product; not all team members are full-time but the team is fixed.Therefore, generally, the costs for a fixed time product development are also fixed.Given the classic ‘Iron Triangle’ of development variables:If we fix time and cost, then the only thing that can vary is the Requirements that are delivered in the fixed time for the fixed cost.It is quite probable that the initial Product Backlog will contain more PBI than could reasonably be developed in the fixed time available; because the stakeholders/Product Owner has ordered the Backlog by business value, it is relatively straightforward to ‘draw a line’ underneath the lowest PBI in the list that will probably be developed.  We do not remove the lower value PBI because it has been often found during development that a high-value PBI is actually dependant on one of the lower value ones and the ordering has to be amended.Stakeholders need to understand that even though some requirements (PBI) have been requested, it is probable that they will not be delivered.But the Product Backlog scoping does not stop there.  The ‘story Points’ for the PBI are estimates and, by definition, they are not accurate.  In the past, to account for ‘inaccurate’ estimates, organisations have added contingency in time and costs to the estimates.However, in Agile environments where the time and costs are effectively fixed, the development needs some ‘wriggle room’ for when estimates are proved significantly wrong and when requirements change during the development. For an effective Product Backlog, you need to follow Scrum Product Backlog tips.The Minimum Viable Product (MVP)The development team must agree with the Product Owner/Stakeholders which PBI represent the Minimum Viable Product, ie what is the minimum to be delivered in the fixed time in order to accrue the minimum benefit required.There are ‘rules’ how big this MVP can be.  It has been found, from hard-won experience that for a ‘comfortable’ working environment:1. When a team first starts an Agile transformation they should accept PBI in the MVP which represent around 50% to 55% of the estimated effort; ie if there are 200 ‘Story Points’ in the probable PBI, then the MVP should only contain the highest value PBI whose ‘Story Points add up to between 100 and 110.2.When the team and the organisation are reasonably Agile-mature, between 9 months and a year of transformation, the team can accept PBI representing up to 65% of the total estimated effort in the MVP.3.When the team and organisation are fully Agile-mature, PBI representing up to 70% by estimated effort may be accepted in the MVP.  It has been found that no matter how good the teams and organisation are, the variables that come along with all product development make promising more than 70% by estimated effort fraught with problems; the teams must strive not to give stakeholders over-expectations.  The MoSCoW RulesSome Agile Frameworks recommend using a technique called MoSCoW to ‘categorise’ the PBI.  The acronym stands for:Must Haves: Those PBI that is essential to the product; equivalent to the MVP above.Should Haves: Those PBI that is important but there is a workaround for them if they not completed in the fixed timeCould Haves: Those PBI that might be developed if all the Musts and Shoulds have been completed before the end of the fixed timeWon’t Haves:  Those PBI that was initially discovered but was not likely to be completed based on the estimates for the more valuable PBI“The ‘o’s are just for fun”!Using the MoSCoW rules allows the Business Case to be prepared with 3 scenarios:The ‘Best Case’ scenario where all the probable PBI are completed; giving the best benefit in the fixed timeThe ‘Expected Case’ scenario where all the Musts and Shoulds are completed giving the majority of the expected benefits in the fixed timeThe ‘Worst Case’ scenario where only the Musts are delivered giving only the essential expected benefits in the fixed time.Case Study 1:I was working as a business analyst and ‘just-in-time’ Agile trainer/coach for an outsourced team building a replacement system.  The team had 6 full-time business representatives to specify the Agile Requirements (UML Use Cases in this instance).Creation of the Product Backlog went smoothly; a good ‘To-Be’ Business Process Model was created and Use Cases to be included in the new system were identified; there were 92.Unfortunately, I was due to go on 3 weeks holiday, so I briefed the team on how to order the Product Backlog and we ran through some Planning Poker with a few of the Use Cases.When I came back from holiday, I discovered that the team business representatives had had problems in ordering the Product Backlog and had abandoned the attempt because they considered that all the PBI were essential.  Also, the whole team had had problems with Planning Poker because they didn’t know enough about the low-level details.It had been decided to prototype all the Use Cases before estimation and the developers were split into 3 sub-teams for prototyping and the business representatives split into 3 pairs.I had taught the team that the prototyping of any PBI should only go through 3 cycles:1 Investigation where a very rough ‘first draft’ is specified, built and reviewed to make sure that the developers are ‘on the right lines’2.Refinement where the majority of the functionality is specified, built and reviewed3.Consolidation where any ‘tidying-up’ was specified, completed and the complete prototype demonstrated to the wider stakeholder communityIf it takes more than the 3 cycles, then something is wrong with the detailed process being followed.The time taken to produce a prototype should be no more than 2 days but it can be as short as 2 to 3 hours if done in a workshop.Unfortunately, it was decided to pick Use Cases to prototype based on their perceived ‘easiness’ and ‘rotate’ the business representative pairs around the prototype builders such that one pair specified the Investigation, another pair reviewed the Investigation and specified the Refinement and the third pair reviewed the Refinement and specified the Consolidation. At the ‘final’ review, with all 6 business representatives present, the ‘final’ prototypes were significantly different from what was originally specified for the Investigation and ‘recriminations’ took place.  So the prototype developers started again.It had taken 3 weeks to develop the prototypes for 6 PBI!I asked the project manager what his estimate was for completing the prototypes for all the PBI; he calculated that the time that would be necessary was 1 month longer than the specified length of the project.Suffice to say that I worked with the customer representatives to convince them that it would be improbable to complete all the PBI in the fixed time/fixed cost development contract and helped them order the Product Backlog and decide on an MVP. It is worth noting that although this product development had a Vision, there were no stated objectives nor a visible Business Case.I worked with the developers and business representatives (who were full team members) to ‘play’ Planning Poker.Actual development work started one week later; PBI were completed in the fixed time that equated to approximately 70% of the expected business benefit; a further short project was commissioned to bring the expected business benefit up to 90%.Lessons:1. Do not go on holiday at a crucial time during the product development lifecycle!2. If the Product Backlog is not ordered by business value, significant time will be wasted prototyping PBI of low business value3. If prototyping is to be used, then the whole team should do it together in a workshop; all views will be accessible to all team members and a consensus reached in the minimal amount of time4. If you are an Agile Project Manager/Scrum Master it is your responsibility to keep the team ‘on track’ and to question decisions that may cause a risk to the projectCase Study 2:I had been asked to do some Agile coaching for some teams in a global organisation that was undertaking the Agile transformation of one of their divisions to use SAFe®/Scrum; the transformation had been running for 6 months.  There were 4 teams distributed around the globe doing support work to enable 24-hour coverage for this global organisation.The reasons for SAFe®/Scrum for this transition I covered in my first article.When I arrived Product Backlog requests were arriving daily to the team members from systems users and the individual team member decided whether the requests were important enough to interrupt the work that they were already doing; the Product Owners were not involved in the decision-making process at all.  As a consequence, there were many requests that had been started and abandoned in favour of ‘questionable’ higher priorities and I discovered that some requests had been sent to inappropriate team members, the work would have been better carried out by members of the other global teams.Furthermore, although the teams were doing some Relative Estimating at Sprint Planning (not before), they were focusing on time estimates because that was what the requirements management tool required and what management was tracking progress by.  I shall cover the pitfalls of Sprint Planning in my next article.I started resolving the Product Backlog issues by speaking to all the Product Owners, mostly via video-conferencing, to see if they understood the problems that the current Product Backlog processes were causing.  They did have some understanding but explained that that was the way they worked before the Agile transition and believed that changes to the process were out of their control.I helped them devise a workable process whereby all requests would be sent to  the Product Owners  at a collective address.  They would take turns during a 24-hour period to determine, with Product Managers, the relative priority of new requests against those already on the Backlog.  In addition, once a week, they would ‘get together’ to decide which team would handle any unassigned requests; ‘show-stopper’ requests would be handled as a matter of urgency and handled by whichever team was immediately available and could resolve the issue before their end-of-day.By this process, the Product Owners would gain control of the Product Backlog, there would be less questionable priority decisions and there would be fewer ‘disgruntled’ customers.The process was approved by the Product Managers and all team members apprised of the reasons for the new process and their responsibilities within it.It quickly became obvious at daily Scrums that not all team members were passing all requests that came to them directly from customers to the Product Owners; the process was reiterated to these team members but then the productivity of some of these members decreased significantly.  The cause was that they were still working on their ‘favourite’ customers requests but not reporting it to the rest of the team.The Product Owners then had to analyse the central Change Request system for items that had been completed by their teams but had not appeared on the Product Backlog; the Change Request system was not integrated with the Product Backlogs.Eventually, the ‘lesson’ was learned by ‘miscreant’ team members.Lessons1. Without control of the Product Backlog by the relevant authority (Product Owners), it is impossible to police work to give the best business value to the organisation2. Without control of the Product Backlog, the resolution to some requests may be started and then abandoned in favour of other later requests leaving the customer frustrated3.Estimating by time at the task level wastes a great deal of time; more of which in my next article.ConclusionThe Product Backlog is arguably the most important artifact for product development:The PBI must be ordered by business valueThe PBI must be estimated, preferably by using Planning PokerIts content over time must be controlled by the Product Owner or equivalentTeam members must be closely coached and mentored during the early instigation of process change to ensure their understanding of the need for the change and their compliance
Rated 4.0/5 based on 11 customer reviews

How Not To Be Agile – 3. An Effective Product Backlog

300
How Not To Be Agile – 3. An Effective Product Backlog

Introduction

Hello and welcome to this, the third article in the series ‘How Not to be Agile’.

‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits when an organisation, or a part of it, embark on an Agile Transformation.

Last time, I discussed the potential pitfalls of not having a suitable Business Case for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.

This time, I will cover some of the misunderstandings and malpractices that I have come across with respect to the next major item to consider in any Agile framework, the requirements.  The most often used term for the requirements list is the Product Backlog from Scrum; I will use this and other Scrum terminology in this article but you can use whatever names you like; it is the content and management of the requirements list that is important.

I will start with a description of the Product Backlog process and then give examples of what has and could go wrong if not follows the Product Backlog tips.

The Definition of Scrum Product Backlog

Scrum Product

 
Having achieved an agreed Vision and Objectives and decided that the Business Case for the product development is viable, the business stakeholders and development team need to discover a list of ‘business requirements’, at the same level of detail, so that the development team can develop the product in a series of short development timeboxes.

These ‘requirements’ become Product Backlog Items (PBI). 

What is a ‘Requirement’?

Functional Requirements:

There are 3 commonly used ‘structures’ used to express ‘Agile functional requirements’:

Elementary Business Processes (EBP) – the names of EBP, usually extracted from the results of the Business Process Modelling exercise concerned with the area of the business that the product is for; for example:

                                                                                              ‘Capture Customer Details’

Use Cases – from the Unified Modelling Language (UML).  Only the names of the Use Cases, again, usually extracted from the results of Business Process Modelling exercise and the example is the same as for the EBP above
User Stories – a technique from eXtreme Programming which states the user of a business process, the name of the process and why the  process is needed; for example:
                                                                                                    ‘As a sales person
                                                                                  I need to Capture the Customer Details
                                                                                        So that payment can be taken’


For all the 3 ‘requirements’ types, it is only the names of the business process that are needed (with the addition of the other 2 clauses in User Stories); there should be no lower level details in the PBI.
The level of detail for all of the above can be summarised as:

                                            ‘The name of one job, being performed by one person, at one time’

Non-Functional ‘Requirements’:

In addition to the Functional Requirements, the ‘What’, the business will also express the needs of ‘How’ the product will perform such as:

  • All screens must refresh within 5 seconds
  • The system must be available 24/7/365
  • The system must conform to the company marketing graphic language
    and so on and so forth.

These Non-Functional ‘requirements’ can be added to the Product Backlog in a separate section from the Functional Requirements or in a separate ‘document’.

What A PBI Is Not

There was a fashion, that still exists in some places, to have ‘Technical User Stories’; ‘User Stories’ those name technical activities that need to be done; for example:
As a database designer
                                                                         I need to create data access scripts
                                                     So that the product can store and retrieve the data that it needs to use


Such User Stories would just be stating elements of a team member’s work and do not add anything to the understanding of the business needs which the Product Backlog is meant to represent.

It is my strong recommendation that so-called ‘Technical User Stories’ are NOT used because the Product Backlog becomes large, unwieldy, almost impossible to order by business value and prioritisation; the estimated effort for these technical needs are included in the estimation of the ‘business’ PBI; more of which later.

It is true that there may be a for some activities  to set-up the technical environment before the development team can start developing the product, some of which are out of the control of the development team; these activities should take place in parallel with creating the initial Product Backlog.

Creating a Product Backlog

Ordering the Product Backlog

The whole point of Agile is to deliver a product incrementally so that the business can accrue the best value in the shortest possible time.

It, therefore, follows that the product needs to be developed by developing the PBI in the business value order; the highest business value PBI first.

Therefore, the PBI needs to be ordered by business value. I will not go into the techniques for ordering PBI, they are well documented elsewhere but I will give an example, later, of what happened when one team did not use Product Backlog ordering.

Estimating the PBI

We create the initial Product Backlog just after agreeing on the Vision and Objectives and ensuring development viability via the Business Case but before development begins; it needs to be estimated in some way to determine how long it may take to develop the product and consequently how much it may cost to develop.

It is a tenet of all Agile frameworks that only the development team is allowed to estimate the PBI.  Once done, these estimates will ‘inform’ the Business Case and analysis can be made to see if the original ‘high-level’ estimates in the initial Business Case are of the same order; a decision can be made as to whether the development is still viable.

Types of PBI estimating

There are 2 generally used types of PBI estimating:

1. Absolute Estimating:  Whereby each PBI is estimated by how much time it would take go from just its name to ‘potentially shippable’ functionality.  Of course, the tasks include analysis, design, construction and testing and what normally happens is that each ‘skill’ will estimate the time it would take for their part in the process and the times summed to get the overall estimate.

2. Relative Estimating:  Whereby the team chooses the PBI which is likely to be ‘the smallest’.

“The smallest in what respect?”  you ask.  The ‘smallest’ does not directly consider time; the PBI criteria that are considered are size and complexity.

However, opinions of size and complexity will vary amongst all team members depending on their skill and experience; what may seem ‘simple’ to an experienced developer may seem complex to the less experienced person.  Similarly, although the analysis and construction may seem simple, the testing may be complex.

For these reasons, it is highly recommended that Relative Estimating is done using ‘Planning Poker’ which is well described elsewhere (see ‘Planning Poker: An Agile Estimating and Planning Technique’); suffice to say here, that once the team have decided which is the ‘smallest’ PBI, they give it a ‘Story Point’ of 1 and all other PBI are estimated with respect to their individual relative size and complexity compared to the ‘smallest’.

So which estimating technique to use?

1. Absolute Estimating can take a long time; it is akin to the traditional way of estimating for the Project Plan.  Also, it has been established that, generally, we are not very good at estimating in time; the larger the thing we are trying to estimate, the worse our estimates get.  However, the technique is familiar to most people and does not require a change of mindset to produce estimates.

2. Relative Estimating requires a totally different mindset amongst the development team members because, initially, not only are they using unfamiliar criteria to estimate the PBI but also, they are estimating in collaboration with other team members with different skill sets and experience.

Despite there being ample evidence that Relative Estimating takes less time overall and allows the stakeholders and development team to focus on business benefit being delivered, because of the ‘difficulties’ of introducing Relative Estimating, many teams revert to time estimation and tracking time.  Also, as we will see in one of the Case Studies below, an organisation’s choice of requirements management tool can make the use of Relative Estimating seem a waste of time for team members.

Another Potential Problem with Relative Estimating

So, having carried out ‘Planning Poker’, the development team now know the total number of ‘Story Points’ that the development represents; not much good to the business stakeholders who want to know how long it is going to take and how much it is going to cost.

On completion of the initial Product Backlog and before development begins, we need to ‘translate’ this total ‘Story Points’ into time.

An Agile Team’s progress is measured by the number of ‘Story Points’ that they deliver in one Sprint; known as the team’s ‘Velocity’.

So we need a knowledge of the team’s Velocity in order to establish an estimate of how long the development is likely to take; for example, if the total number of ‘Story Points’ is 200 and the team’s velocity for a 2-week Sprints is 10, then the estimated time to complete all the PBI is:

         200 ‘Story Points’ / 10 ‘Story Points per Sprint  x 2 (the number of weeks per Sprint) = 40 weeks

However, at the start of an Agile transition, we do not know what the team’s Velocity is or will be.  There are 2 methods to determine what the Velocity may be:

1. The team takes one of the ‘smallest’ PBI (with a Story Point of 1) and does a traditional break down to the tasks involved and estimate those tasks in time;  1 ‘Story Point’ is equivalent to the time represented by the sum of the times estimated for all the tasks
The team’s Velocity may be estimated by:
                                      ‘The number of working days in the Sprint / the estimated days for 1 Story Point’
For example, if the ‘time estimate’ for a PBI of 1 ‘Story Point’  is 1 day:
                                             10 working days in 2-week Sprint / 1 day = Velocity of 10
This velocity can then be used in the formula above to determine the estimate for the potential total time for the development.

2. The development team is allowed to start development for 2 or 3 Sprints taking PBI from the top of the Product Backlog.  At the end of the ‘experiment’ period, the total number of ‘Story Points’ for the completed PBI divided by the number of Sprints completed becomes the Velocity to use in the formula above to determine the estimate for the potential total time for the development.

The potential problem with this method is that management have to release funds for this experimental period without knowing the values to feed into the Business Case to determine whether the product development is viable before development begins.

Once teams have completed 1 product development, we recommend that the team members are kept together for other product developments even though the business area or technology may be different.  Having a team that works well together is more important than creating teams in an ad-hoc manner.  A team’s Velocity varies insignificantly over different product developments and so can be used directly in the formula above to determine the estimate for the potential total time for the development.\

Scoping the Product Backlog

Generally, Agile product developments have strict deadlines so that the major benefits can be accrued; benefits such as competitive advantage, meeting marketing needs, meeting customer expectations or complying with regulations.

Also, Agile teams comprise all the skills necessary to take the PBI from ‘names’ to a potentially shippable product; not all team members are full-time but the team is fixed.

Therefore, generally, the costs for a fixed time product development are also fixed.
Given the classic ‘Iron Triangle’ of development variables:
Scoping the Product Backlog


If we fix time and cost, then the only thing that can vary is the Requirements that are delivered in the fixed time for the fixed cost.

It is quite probable that the initial Product Backlog will contain more PBI than could reasonably be developed in the fixed time available; because the stakeholders/Product Owner has ordered the Backlog by business value, it is relatively straightforward to ‘draw a line’ underneath the lowest PBI in the list that will probably be developed.  We do not remove the lower value PBI because it has been often found during development that a high-value PBI is actually dependant on one of the lower value ones and the ordering has to be amended.

Stakeholders need to understand that even though some requirements (PBI) have been requested, it is probable that they will not be delivered.

But the Product Backlog scoping does not stop there.  The ‘story Points’ for the PBI are estimates and, by definition, they are not accurate.  In the past, to account for ‘inaccurate’ estimates, organisations have added contingency in time and costs to the estimates.

However, in Agile environments where the time and costs are effectively fixed, the development needs some ‘wriggle room’ for when estimates are proved significantly wrong and when requirements change during the development. For an effective Product Backlog, you need to follow Scrum Product Backlog tips.

The Minimum Viable Product (MVP)

The development team must agree with the Product Owner/Stakeholders which PBI represent the Minimum Viable Product, ie what is the minimum to be delivered in the fixed time in order to accrue the minimum benefit required.

There are ‘rules’ how big this MVP can be.  It has been found, from hard-won experience that for a ‘comfortable’ working environment:

1. When a team first starts an Agile transformation they should accept PBI in the MVP which represent around 50% to 55% of the estimated effort; ie if there are 200 ‘Story Points’ in the probable PBI, then the MVP should only contain the highest value PBI whose ‘Story Points add up to between 100 and 110.

2.When the team and the organisation are reasonably Agile-mature, between 9 months and a year of transformation, the team can accept PBI representing up to 65% of the total estimated effort in the MVP.

3.When the team and organisation are fully Agile-mature, PBI representing up to 70% by estimated effort may be accepted in the MVP.  It has been found that no matter how good the teams and organisation are, the variables that come along with all product development make promising more than 70% by estimated effort fraught with problems; the teams must strive not to give stakeholders over-expectations. 

The MoSCoW Rules

Some Agile Frameworks recommend using a technique called MoSCoW to ‘categorise’ the PBI.  The acronym stands for:

  • Must Haves: Those PBI that is essential to the product; equivalent to the MVP above.
  • Should Haves: Those PBI that is important but there is a workaround for them if they not completed in the fixed time
  • Could Haves: Those PBI that might be developed if all the Musts and Shoulds have been completed before the end of the fixed time
  • Won’t Haves:  Those PBI that was initially discovered but was not likely to be completed based on the estimates for the more valuable PBI

“The ‘o’s are just for fun”!

Using the MoSCoW rules allows the Business Case to be prepared with 3 scenarios:

  • The ‘Best Case’ scenario where all the probable PBI are completed; giving the best benefit in the fixed time
  • The ‘Expected Case’ scenario where all the Musts and Shoulds are completed giving the majority of the expected benefits in the fixed time
  • The ‘Worst Case’ scenario where only the Musts are delivered giving only the essential expected benefits in the fixed time.


Case Study 1:

I was working as a business analyst and ‘just-in-time’ Agile trainer/coach for an outsourced team building a replacement system.  The team had 6 full-time business representatives to specify the Agile Requirements (UML Use Cases in this instance).

Creation of the Product Backlog went smoothly; a good ‘To-Be’ Business Process Model was created and Use Cases to be included in the new system were identified; there were 92.

Unfortunately, I was due to go on 3 weeks holiday, so I briefed the team on how to order the Product Backlog and we ran through some Planning Poker with a few of the Use Cases.

When I came back from holiday, I discovered that the team business representatives had had problems in ordering the Product Backlog and had abandoned the attempt because they considered that all the PBI were essential.  Also, the whole team had had problems with Planning Poker because they didn’t know enough about the low-level details.

It had been decided to prototype all the Use Cases before estimation and the developers were split into 3 sub-teams for prototyping and the business representatives split into 3 pairs.

I had taught the team that the prototyping of any PBI should only go through 3 cycles:

1 Investigation where a very rough ‘first draft’ is specified, built and reviewed to make sure that the developers are ‘on the right lines’

2.Refinement where the majority of the functionality is specified, built and reviewed

3.Consolidation where any ‘tidying-up’ was specified, completed and the complete prototype demonstrated to the wider stakeholder community

If it takes more than the 3 cycles, then something is wrong with the detailed process being followed.

The time taken to produce a prototype should be no more than 2 days but it can be as short as 2 to 3 hours if done in a workshop.

Unfortunately, it was decided to pick Use Cases to prototype based on their perceived ‘easiness’ and ‘rotate’ the business representative pairs around the prototype builders such that one pair specified the Investigation, another pair reviewed the Investigation and specified the Refinement and the third pair reviewed the Refinement and specified the Consolidation.
 
At the ‘final’ review, with all 6 business representatives present, the ‘final’ prototypes were significantly different from what was originally specified for the Investigation and ‘recriminations’ took place.  So the prototype developers started again.

It had taken 3 weeks to develop the prototypes for 6 PBI!

I asked the project manager what his estimate was for completing the prototypes for all the PBI; he calculated that the time that would be necessary was 1 month longer than the specified length of the project.

Suffice to say that I worked with the customer representatives to convince them that it would be improbable to complete all the PBI in the fixed time/fixed cost development contract and helped them order the Product Backlog and decide on an MVP. It is worth noting that although this product development had a Vision, there were no stated objectives nor a visible Business Case.

I worked with the developers and business representatives (who were full team members) to ‘play’ Planning Poker.

Actual development work started one week later; PBI were completed in the fixed time that equated to approximately 70% of the expected business benefit; a further short project was commissioned to bring the expected business benefit up to 90%.

Lessons:

1. Do not go on holiday at a crucial time during the product development lifecycle!

2. If the Product Backlog is not ordered by business value, significant time will be wasted prototyping PBI of low business value

3. If prototyping is to be used, then the whole team should do it together in a workshop; all views will be accessible to all team members and a consensus reached in the minimal amount of time

4. If you are an Agile Project Manager/Scrum Master it is your responsibility to keep the team ‘on track’ and to question decisions that may cause a risk to the project

Case Study 2:

I had been asked to do some Agile coaching for some teams in a global organisation that was undertaking the Agile transformation of one of their divisions to use SAFe®/Scrum; the transformation had been running for 6 months.  There were 4 teams distributed around the globe doing support work to enable 24-hour coverage for this global organisation.

The reasons for SAFe®/Scrum for this transition I covered in my first article.

When I arrived Product Backlog requests were arriving daily to the team members from systems users and the individual team member decided whether the requests were important enough to interrupt the work that they were already doing; the Product Owners were not involved in the decision-making process at all.  As a consequence, there were many requests that had been started and abandoned in favour of ‘questionable’ higher priorities and I discovered that some requests had been sent to inappropriate team members, the work would have been better carried out by members of the other global teams.

Furthermore, although the teams were doing some Relative Estimating at Sprint Planning (not before), they were focusing on time estimates because that was what the requirements management tool required and what management was tracking progress by.  I shall cover the pitfalls of Sprint Planning in my next article.

I started resolving the Product Backlog issues by speaking to all the Product Owners, mostly via video-conferencing, to see if they understood the problems that the current Product Backlog processes were causing.  They did have some understanding but explained that that was the way they worked before the Agile transition and believed that changes to the process were out of their control.

I helped them devise a workable process whereby all requests would be sent to  the Product Owners  at a collective address.  They would take turns during a 24-hour period to determine, with Product Managers, the relative priority of new requests against those already on the Backlog.  In addition, once a week, they would ‘get together’ to decide which team would handle any unassigned requests; ‘show-stopper’ requests would be handled as a matter of urgency and handled by whichever team was immediately available and could resolve the issue before their end-of-day.

By this process, the Product Owners would gain control of the Product Backlog, there would be less questionable priority decisions and there would be fewer ‘disgruntled’ customers.

The process was approved by the Product Managers and all team members apprised of the reasons for the new process and their responsibilities within it.

It quickly became obvious at daily Scrums that not all team members were passing all requests that came to them directly from customers to the Product Owners; the process was reiterated to these team members but then the productivity of some of these members decreased significantly.  The cause was that they were still working on their ‘favourite’ customers requests but not reporting it to the rest of the team.

The Product Owners then had to analyse the central Change Request system for items that had been completed by their teams but had not appeared on the Product Backlog; the Change Request system was not integrated with the Product Backlogs.

Eventually, the ‘lesson’ was learned by ‘miscreant’ team members.

Lessons

1. Without control of the Product Backlog by the relevant authority (Product Owners), it is impossible to police work to give the best business value to the organisation

2. Without control of the Product Backlog, the resolution to some requests may be started and then abandoned in favour of other later requests leaving the customer frustrated

3.Estimating by time at the task level wastes a great deal of time; more of which in my next article.


Conclusion
The Product Backlog is arguably the most important artifact for product development:

  • The PBI must be ordered by business value
  • The PBI must be estimated, preferably by using Planning Poker
  • Its content over time must be controlled by the Product Owner or equivalent
  • Team members must be closely coached and mentored during the early instigation of process change to ensure their understanding of the need for the change and their compliance

Steve

Steve Ash

Blog Author

Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’.  He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner.  He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.
 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Agile Scrum Roles And Responsibilities

Agile, Scrum, Waterfall, Kanban are different project management frameworks which are helping the companies to increase the productivity. These frameworks were created by the IT companies and especially web and application development companies because they needed a path but on which each and every employee can perform his daily tasks. However, out of these four frameworks, the Scrum is the most widely used framework in all the companies despite their nature of work. That is why in this article we are going to discuss the Scrum in detail to give you a better idea about this iterative framework which is making easier for the companies to complete their project. Scrum Objective: The basic objective of the Scrum is to keep the entire team on the same page throughout the project. The scrum framework allows the cross-functional work of the team of 4 to 10 members to provide the regular details and information sharing liberty so they can produce the best result. Scrum is a more like philosophical than the technical. It is a framework that can only be used as the guidance and there is no constant in it. All the success of the Scrum depends on the interactions among the stakeholders as it does the process. Scrum roles and responsibilities: The techniques of Scrum has become very popular and now considered to be the most important thing to do before starting any project. That is why the demand of the scrum masters and other professions related to the scrum has also increased, and people now are searching about the term scrum more. The scrum is a very specific and précised framework that is why it comprised on the following roles. Scrum Master Product Owner Scrum Team Stakeholders Because the term Agile is often get associated with the project managers that is why many people believe that the Scrum Master is also a term for the project managers. However, the Scrum Master serves very different purposes than the project manager. The Scrum Master works as a facilitator rather than the authoritative person who is responsible for the project delivery. The Scrum Master is a coach, motivator and problem solver who can only assist the team by using all his experience of Scrum framework. According to many Scrum Masters, applying Scrum within an organization is not the actual scrum process. You have to make the organization to accept your new role and then change its culture which is the most difficult thing to do in any company. The prominent role of every Scrum Master should be to enhance the power of the team by committing them to the sprint goals without any interference from the management. Let’s discuss the major roles of all the above points separately. Scrum Master: The Scrum Master is considered to be the top-dog in every organization because companies usually hire them and don’t treat them as permanent employ that is why they are with no authority. It is their duty to remove all the hindrance or obstruction in the way of achieving any goal. It is also their role to enforce scrum ceremonies and processes. They are the ones who commit to goals and deadlines on behalf of the team. Product Owner: The product owner is responsible for conveying the vision of the stakeholders to the team. They have the authority to alter the scope. The Product Owners are responsible for the return on investment (ROI) that is why they occupy an authoritative position in the firm. Because they convey the vision of the stakeholders that is why they are the voice of the stakeholders. Not only with the team, but they also communicate with the stakeholders about progress and problems. Scrum Team: The Scrum Team is responsible for all the activities that lead them towards their sprint goals. They have to work with the Scrum Master to prioritize the items from the product backlog in the sprint planning. Once committed, it is their responsibility to fulfil the commitment and deliver the agreed results on time with great quality. The Scrum Master is not responsible for keeping his team organized that is they it is the duty of the Scrum Team to get self-organized. They have to be agile in the office and have to attend every standup and other ceremonies. They have to participate in all the meetings despite their nature and have to ensure that all the findings of the meetings are getting practically addressed in the project. Stakeholders: The Stakeholder has to keep a healthy relationship with the Product Owner in order to share every detail regarding his project. The Stakeholder is responsible for conveying his wishes and concerns to the product owner or else the product owner would not be responsible for his project quality and time duration. The Stakeholder has to provide regular input to queries from the Product Owner. Prioritizing the work affectively with the Product Owner is another job that the Stakeholder has to do to ensure his project development. Keep taking updates or keep giving updates regarding any change in the plans.
Rated 4.0/5 based on 20 customer reviews
1151
Agile Scrum Roles And Responsibilities

Agile, Scrum, Waterfall, Kanban are different proj... Read More

Difference Between Agile and Scrum

Agile describes a set of guiding principles that uses iterative approach for software development, while Scrum is a specific set of rules that are to be followed while practicing the Agile software development. Agile Agile management represents various o software-development methodologies that have been influenced by iterative and incremental development, which includes Extreme Programming (XP), Rational Unified Process (RUP), Scrum, and others. Agile process or methods provide an environment where there is constant evolution in requirements and evolution as a result of collaboration between self-organising cross-functional teams. Agile methodologies foster a disciplined project-management approach that encourages a set of best practices, allowing a rapid delivery of high-quality software and enhancing a business approach, which aligns development with the customer needs. The Agile methodologies stand in contrast to the traditional waterfall methodology, where all the requirements are initially analysed and documented before the development begins. While in Agile approach, requirements are like the actual software-development advances within each iteration. This approach provides flexibility in accommodating changes in the requirements and priorities of the business. The Agile development process aligns with the concepts of Agile Manifesto. Also known as Manifesto for Agile Software Development, the Agile Manifesto is a formal declaration of 4 key values and 12 principles supporting an iterative approach to software development. The Agile development methodology enables assessment of project direction throughout the development lifecycle. This is achieved through regular iterations, and when revaluation is done at every iteration, it greatly reduces the development costs and time. Agile helps the companies to build the right product. Benefits of Agile include as follows: • Benefits the Customers In the traditional waterfall model, the high-value features are developed and delivered in longer cycles compared to the Agile approach, which enables delivery within short cycles. This enables the vendors to be more responsive to the development requests of the customers. • Benefits the Vendors Adopting Agile benefits the vendors by having an improved customer satisfaction and customer retention, leading to more customer contacts through positive references. The Agile allows the vendor’s focus to be on the development effort of high-value features, decrease the overheads, and improve efficiency. • Quality With Agile development, there is a regular inspection of the working product, with testing integrated at every iteration, as it develops throughout the lifecycle. This in turn retains the quality of the product and also allows the product owner to make necessary adjustments whenever a quality issue arises. • Visibility Agile methodology is a collaborative approach that encourages active user participation throughout the product development. This gives an exceptional and clear visibility of the project’s progress and product development to the stakeholders. • Cost Control Agile development process has fixed timescale where the requirements emerge and evolve as the project progresses and the product is developed. This enables a fixed budget. • Risk Management In Agile methodology, small incremental releases are made visible to the product owner throughout the development cycle, which helps identify issues at an early stage, and it makes easier to respond to change, if any. Agile development ensures clear visibility, which allows necessary decisions to be taken at the earliest possible opportunity. Scrum Scrum, on the other hand, is a subset of Agile. A Scrum is a simple and flexible Agile methodology for software development. The Scrum is not a technique or a process but a lightweight and simple framework to address complex problems of a project and deliver a high-value product creatively. The major distinguishing attributes of Scrum are as follows: • Simplicity The development in Scrum is done in sprints, which are 1, 2, and 3 weeks in length. The Scrum team consists of: 1. Product Owner: The major responsibility of the product owner is to maximize the value of the product and work of the development team. Additional duties include managing the product catalogue. 2. Scrum Master: The development team consists of self-organising professionals who turn the product catalogue into product increment at the end of each sprint. 3. Development Team: The Scrum Masters make sure that the Scrum team is abiding by the Scrum theory and its rules. • Flexibility In the traditional waterfall model, when the business and technical requirements are documented and detailed, it results in endless documentation. The Scrum makes use of user stories to describe the functions needed to be developed. A tool called Pivotal Tracker is used to store these user stories in a backlog. If a change needs to be made or a need arises to add to the user stories, in that case the team can adjust as early as the next sprint. This allows the business to change their minds and the development team to be flexible enough to adjust to those changes. The ability to accommodate change is a powerful attribute of the Scrum methodology. • Communication and Collaboration In Scrum methodology, the communication between business users takes place on a daily/weekly basis according to the sprint schedule. This close communication and collaboration is a crucial factor, promoting the success of the Scrum methodology. The Scrum team achieves collaboration in following ways: 1. The Product Owner, the Scrum Master, and the development team work closely on a daily basis. 2. Sprint-planning meetings are conducted, which allows the development team to organise its work based on the knowledge gathered from the business priorities. 3. Conducting daily scrum meetings where the development team can account for the work completed, its future prospects, and deal with issues if any. 4. Conducting sprint reviews allows the team members to evaluate their former work by recommending better practices with every sprint. There are more details on Agile & scum differences
Rated 4.0/5 based on 20 customer reviews
1100
Difference Between Agile and Scrum

Agile describes a set of guiding principles that u... Read More

Agile Project Management Vs. Traditional Project Management

In this fast-moving world, project management has become one of the most important pillars that are helping businesses run without any glitch in their processes. Both small and large scale organizations around the world are exploiting technology and depending on project management systems to deliver the software development project successfully. Whether it is team workflow management or timing, these tools help to ensure that everything is going well without any obstacles. While there are tens of different project management approaches, Agile is considered one of the most practical and flexible software development mechanism that exist today. It is capable of executing a variety of tasks, but what sets it apart from others? Let’s find it out. Here’s a brief comparison of Agile management and traditional project management software:                                                                                                                    Traditional vs Agile Project Management Overview of Agile and Traditional Project Management What is Traditional Project Management? The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in sequence. Its concept depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure above. The entire project is planned upfront without any scope for changing requirements. This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues. What is Agile Project Management? When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility. It is an iterative approach that focuses more on incorporating customer feedback and continuous releases with every iteration of software development project. The basic concept behind Agile software development is that it delves into evolving changes and collaborative effort to bring out results rather than a predefined process. Adaptive planning is perhaps the biggest feature of Agile and one that makes it a crowd favorite among project managers. Scrum and Kanban are two of the most widely used Agile frameworks. They are very well known for encouraging decision-making and preventing time consumption on variables that are bound to change. It stresses customer satisfaction and uses available teams to fast-track software development at every stage. The table below shows the major differences between Agile project management and traditional project management.                                                                                Table: Agile project management vs traditional project management Why is Agile Preferred and why not the traditional project management? Agile is preferred by most developers and managers because of a variety of reasons. Let’s have a look at the most common ones: Project complexity Traditional: This method is the best fit for small or less complex projects as it follows linear approach. Sudden changes in the project or any other complexities can block the entire process and make the team go back to step one and start all over again. Agile: This is the best methodology to follow in case of complex projects. A complex project may have various interconnected phases and each stage may be dependent on many others rather than a single one as in simple projects. So, Agile methods are preferred for large complex projects, as they can respond better to such structures. Adaptability Traditional: This approach works with a belief that once a phase is done, it will not be reviewed again. So, it is not adaptable to rapid changes in the work plan. In case if any sudden situation arises or any change in the requirements from the client’s side, traditional approach fails to adapt to the new change. The only choice is to start from the very beginning once again. This wastes a lot of effort and time in the process. Agile: The adaptability factor is very high in this methodology since it is not linear. Complex projects consist of several interconnected stages, where a change in one stage can cause an effect on another. And the project managers can take calculated risks in such scenario, as there is a chance of high adaptability.  Scope for feedback and changes Traditional Each and every process is clearly detailed and defined at the start of the project in the traditional approach. It cannot deal with any big change or feedback that might require a change in the process. Mostly, the project delivery time and budget are fixed, allows change very rarely. Agile There is a high acceptance for feedback and change in this method. The process is very flexible and allows constant feedback that can help to provide better output within the fixed project delivery time. The main reason that managers or developers choose agile direction is for the flexibility it offers. Developers working with Agile management are able to respond to customer requests quickly as they are only addressing small parts of the project at a time and the customer validates each iteration or sprint before finalizing. Some of the important characteristics of Agile development Breaks project into parts Agile divides a project into parts (called iterations) where the release is sent to the customer after every single iteration. Additionally, the success of the project can be easily foreseen through the success of these iterations. This removes the need for upfront planning completely. Self-organized As mentioned above, Agile uses a parallel mode of management. Employees of a company are not managed by a central line of control, but by groups. For example, in Agile, there may be eight teams working on a single project. Each team is managed by itself without external guidance. The teams only interact with each other for project discussion and process linking as they are otherwise not self-sufficient. Generally speaking, an Agile project consists of three parts: The product owner – the expert on the project (for which the product is being developed) and is the main person who oversees the projects The scrum master – this person manages the process involved in Agile. He/she looks after the iterations and its completion The team – individuals who play significant and minor roles in the software development process Customer Engagement In Agile, customer engagement is at the very top. The customer is regarded highly in its frameworks as after every iteration, feedback is generated and acted upon. Overall, Agile is clearly the winner among project management systems. When compared with other traditional approaches, Agile’s features come to the fore and reiterate why it is one of the top software used by companies globally. Can Agile Coexist with Other Approaches? This is a question asked by many project managers, and opinions of experts seem to be divided. While some say it is possible for Agile to coexist with traditional project management systems, they suggest being cautious and using them for different terms. For example, using two different approaches on the same project can be counter-productive and highly explosive. As Agile and most other frameworks are totally contrasting to each other, the projects may go for a toss. On the other hand, some experts believe that it is not possible for Agile and other tools to co-exist because of their contrast. Using them together can cause disorder in the entire company system, making the productivity to go for a toss. Agile vs Traditional- Adoption Growth According to a recent online survey of 601 IT and development professionals, it is proved that Agile is the new typical formula for project success. The majority of projects and development teams are now adopting this methodology, while the traditional waterfall approaches have many flaws.    Traditional organizations vs. #Agile organizations #SALC16 pic.twitter.com/bBgxkQB1fI — Scrum Alliance (@ScrumAlliance) January 20, 2016 Agile was first introduced about 15 years ago as a substitute for traditional software development approaches. Many people considered it as challenging to implement traditional approach practices and Agile adopters stated that this new style of software development improves team collaboration and is more customer-centric.  Though Agile method was present more than a decade ago, the vast majority of organizations have adopted the practice in the last 5 years. Moreover, the survey reported that agile adoption saw an inflection point between the year 2009-2010. As shown in the above figure, agile adoption seems to have slow incremental growth till 2008 and then its growth was accelerated after gaining traction in the market. Reasons for the transition to Agile Most of the organizations who transitioned from traditional to agile project management have listed the following reasons: Improves collaboration between teams- 54% Enhances the quality level of software in organizations- 52% Results in enhanced customer satisfaction- 49% Speeds time to market- 43% Reduces development cost- 42% The Verdict In the traditional software development, the customer involves only before the start of the development process. So, there might be a number of mistakes and a large amount of money needs to be spent to rework on them. Since in the Agile software development, the customer involves at each stage, the corrections can be made once the defects are detected. This helps us in saving cost. As we can see, Agile project management is really in-demand for teams. It helps the team to work on the top priority ones at the right time and allows them to walk through the risks much faster than they would with traditional project management tools.  
Rated 4.0/5 based on 2 customer reviews
1876
Agile Project Management Vs. Traditional Project M...

In this fast-moving world, project management has ... Read More