Archive | scrum RSS feed for this section

Product Backlog Refinement in SCRUM

16 Jun

Within the Scrum Framework – there are numerous GASPs (Generally Accepted Scrum Practices). The following 4 meetings are all GASPs:

• Sprint Planning
• Daily Stand-up
• Show and Tell/Sprint Review
• Sprint Retrospective

There have been efforts to include a 5th meeting to the list of GASPs:

• Product Backlog Refinement (PBR session)

AIM OF THE PBR SESSION
The overall aim of this meeting is to manage the product inventory and ensure that the product backlog (i.e. anything outside of a Sprint) is up-to-date. This is done through the following PBR activities:

I) Refinement:
• Progressively breaking down large items (EPICs) into smaller items (features/use cases etc) that can be implemented in a single Sprint
• Grouping items based on commonality (technical delivery/product goal etc)
• Adding detail – such as acceptance criteria – to items in order to generate a common understanding

II) Estimation:
• Pre-Sprint, high-level estimation of items in the product backlog will facilitate delivery planning
• Methods include – story point estimation (e.g. planning poker on the Fibonacci sequence), t-shirt sizes, bucket estimation, blink estimation

III) Prioritisation:
• Items are prioritised according to business value (this is primarily identified by the Product Owner/stakeholders/user data)
• Items are independent as per the INVEST criteria – therefore the order of items on the product backlog leads to a prioritised Sprint backlog

IV) “Ready” state:
• Items are discussed – with issues/questions/actions being identified
• Agreement on what needs to be done in order to get items into “Ready for development”/”Ready for Sprint”

V) Communication:
• Team understands the bigger picture – i.e. the vision beyond the current Sprint

VI) Ideation:
• New, high-level user stories are discussed and added to the Product Backlog
• Bringing together members of the business and technical team to discuss ideation facilitates collaborative product development within a cross-functional team

GENERAL FORMAT OF THE PBR SESSION
I) Timing:
• Regular – product priorities/understandings are dynamic. The product backlog must therefore be responsive to change. It is recommended that PBR sessions are held every Sprint or 2
• Scheduled – Typically mid Sprint in order to avoid conflict with the Sprint Planning/Show and Tell/Retrospectives
• Duration – Timeboxed – typically to 1.5 – 2 hours

II) Participants:
• The Product Owner is primarily responsible for the Product Backlog. The Scrum Master is responsible for facilitation and the removal of obstacles. Attendance of both is therefore mandatory
• Team members – invited – however attendance is optional. Details of which stories will be discussed in the session should be provided in advance (this enables users to decide whether or not to attend)
• Small number of stakeholders can be invited to assist with prioritisation. Representation from both the business and technical team is preferred

III) Agenda:
• The entire product backlog is not discussed. Instead the agenda should cover items that are likely to come up in the next 3-4 Sprints
• The session should aim to achieve the following:
•• Agreement on story breakdown/high level definition
•• High-level estimation
•• Item prioritisation
•• Agreement on actions necessary to get items into a “Ready” state
•• Discussion of any new ideas
• At a high level – the aim of the PBR session is to ensure that items in the Product Backlog meet the DEEP criteria (Detailed Appropriately, Estimated, Emergent and Prioritised)

Advertisements

Applying Agile principles to requirement analysis

23 May

Background

The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase             -> Requirement Analysis (Business Analysts/Product Owners)

Design Phase                -> UX (Designers/Usability Experts)

Development Phase  -> Software Development (Developers)

Testing Phase               -> QA (Manual Testers and Developers in Test)

Delivery Phase             -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”.  This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes. Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.

Conclusion

Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirement collaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.

How to measure Agile maturity on your project

28 Apr

What is “Agile”?

The concept of “Agile” was popularised in 2001 with the publication of the Agile Manifesto (http://agilemanifesto.org/). The manifesto set out a number of principles which – when successfully applied – would improve the process of software development.

Over time these Agile principles – valuing individuals and interactions over processes, responding to change, collaboration etc – were applied to projects in various industries. “Agile” made the transition from IT to general management practice in a similar manner to lean/six sigma’s evolution from its manufacturing origins.

With its increasing popularity – Project Managers were widely encouraged to implement Agile principles in order to successfully deliver projects (http://pmdoi.org/).

Why measure Agile maturity?

1) Let’s imagine the following scenario:

You’ve heard that Agile is popular with other PMs – but you’re not sure about it. You decide to try Agile on your project. You invest £10,000 on staff training and purchasing Agile artefacts (an online dashboard, Sprint boards etc). One year later – you want to find out whether your investment was worthwhile. You measure the team’s current delivery (time/cost/quality metrics) and compare this against an earlier benchmark. You notice very little improvement.

As a PM – do you attribute this to the team’s failure to implement Agile principles (i.e. due to a low level of adoption)? Or was Agile the incorrect methodology for this team (i.e. due to the nature of the product would a more structured approach have had greater efficacy)?

Without a measure of Agile maturity – how can you answer these questions?

2) In another scenario:

You’re a PM who is completely sold on “Agile”. You believe in it passionately – the more Agile a team is the better. You have a total of 7 teams across the business using Agile.

How can you identify the Agile improvement areas for each of the 7 teams? How can you provide feedback on their Agile performance?

3) Last scenario:

You dislike Agile intensely. It’s a methodology that has being extended to fit every size/structure of team. You use Waterfall – and want to convey that this approach works for your team.

Imagine that you could measure your team’s success using the standard metrics – and also show that this success has been possible without being “Agile”. Perhaps then there would be less pressure from management to adopt Agile principles.

Broadly speaking therefore – the pragmatist (scenario 1), Agile evangelist (scenario 2) and Agile sceptic (scenario 3) would each benefit from the ability to quantify Agile adoption. So what types of Agile assessments are available?

How to measure Agile maturity?

There are 4 widely available, self-administrable, free assessments that can provide teams with a detailed breakdown of performance across key Agile areas:

1) Mike Cohn & Kenny Rubin (http://comparativeagility.com/): This assessment measures a team’s performance across 7 dimensions: teamwork, requirements, planning, technical practices, quality, culture and knowledge creation. With approximately 100 questions – this is one of the most detailed assessments available online.

2) Thoughtworks (http://www.agileassessments.com/online-assessments/agile-self-evaluation): Consisting of 20 questions – and providing a detailed summary report – this assessment was developed by a leading consultancy. The assessment is best administered as a group exercise- as this encourages dialogue and leads to a more balanced viewpoint.

3) The Nokia Test (http://jeffsutherland.com/nokiatest.pdf): This is one of the oldest assessments available – and was produced by Jeff Sutherland (a key figure in the Agile community). The Nokia Test focuses on the iterative nature of Agile and the adoption of the Scrum framework.

4) Agile Karlskrona test (http://www.piratson.se/archive/Agile_Karlskrona_Test.html or http://www.mayberg.se/archive/Agile_Karlskrona_Test.pdf): an incredibly simple self-assessment that provides a team with a basic snapshot of their performance.

Limitations

The 4 assessments mentioned above provide valuable feedback: improvement areas are flagged and successes are recognised. They also encourage dialogue throughout the team in terms of best practices.

It is worth adding however that “Agile” is based on a descriptive manifesto (e.g. you should value customer collaboration) – rather than a prescriptive manifesto (e.g. you should produce a customer collaboration tracker which should be reviewed biweekly with the PMO team). The origins of Agile (in terms of a descriptive manifesto), and the lack of a definitive maturity model, mean that although measuring Agile maturity is worthwhile – it is an imprecise science.