Strong focus on delivering continuous business value while executing Agile projects

[ivanov...@gmail.com]

Hi,

My name is Diana Ivanov. I have been a Soft Development manager and playing the Scrum Master role for the last 5 years.

I’d like to share with this community an approach we adopted and try to follow consistently that is focused on continuous delivery of business value.

 

I’m looking to gather feedback from other Scrum practitioners.

 

The approach is based on ensuring consistent ratio of User Stories type each Sprint.

For our organization we determined this ratio to be: 60%-20%-20% where:

1. 60 % are Functional stories that meet the Definition of Done for production code

2. 20 % are stories focused on Advanced Design (AD): building pretotypes, prototypes, establishing system architecture, etc

3. 20 % are Non-Functional stories: e.g. establishing the tools that enable continuous integration, adding source code to source control system, setting up the build system, creating Release branches and so on.

Background: The issue that probably most of you had to deal with, while executing complex projects is: How much design in advance is “enough design” before the team can start deliver actual business value.

We all know that the sooner you have a demoable software the sooner you can validate with customers and stakeholders that you properly understood the requirements and you managed to solve the right problems for the user.

Bottom line, we want to start getting the early validation as soon as possible without building too much code. The only caveat to that is that we still want to do reasonable analysis and just enough design.

 

Why: How is this approach helping us and what are the challenges that it solves.

We have two main challenges:

1. Sometimes the requirements that we gather from the customers are not very clear or we don’t always understand the exact problem that the customer wants us to solve

2. We work with a less experienced offshore team, experience in terms of product domain or technical competencies.

Solution:

1. For every new feature or complex architectural problem we create Advanced Design Stories that have to be executed prior to the actual implementation. The output of these stories can be in the form of:

1. UI pretotype/prototype. We can share this with internal and external customers and get validation in terms of intended User Workflow and business use cases.

2. Architectural prototypes allowing to define the detail design for establishing the system architecture. These stories are also delivering interface definition so multiple teams can start work in parallel building components of the system, knowing the interface contracts.

1. Non-Functional stories are also required so the proper tools and processes can be established to enable the execution team to make quick progress

2. Functional Stories are defined based on the outcome of the Advanced Design and there is sufficient clarity in terms of Requirements and Acceptance Criteria for each story.

   Benefit:

1. The AD stories allow us to get early validation from stakeholders and customers. They ensure that we can define well groomed stories that less experienced team can execute efficiently and reduce the re-work.

2. Enforcing of 60 % functional stories every iteration ensures that the team is actually delivering incremental product that can get early exposure for additional usability and acceptance testing.

[David Grant]

Thanks for sharing Diana. 

Are there any cases where the AD stories are not validated by the customer?  What is the root cause of the requirements from the customer not being very clear?

Dave

[ivanov...@gmail.com]

Posting a reply to Dave's questions:

1.Yes, some of the AD stories are purely architectural, in this case the goal is to choose the right technology or proof the interface.

For these type of stories we don't look for customer's validation.

 

Are there situations where the customer does not approve of the AD: 

    Yes, we have had these situations. Especially during validation from the internal customers. This is when we establish the approach and the preliminary cost to develop the solution.We had situations where based on the cost the Portfolio parter choose to prioritize the requirement lower or completely take it out of scope for the current release.

  

2. Regarding the second part of Dave’s question, in some cases the customer (internal/e.g. Portfolio or external) may request a feature or an enhancement based on his understanding of the system.

When development starts the analysis we may find out that we can deliver this request by optimizing an existing feature or by changing the user workflow.

[Asad Safari]

Good story,

Thanks for sharing this experience.

Asad

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.