Group - AgileBusinessAnalysis/01_TEAM GitHub Wiki

Evaluation criteria on group level are categorised into five knowledge area of the Business Analysis Body of Knowledge (BABOK):

  • Elicitation and Collaboration
  • Requirements Lifecycle Management
  • Strategy Analysis
  • Requirements Analysis and Design Definition
  • Solution Evaluation

The objective of this page is to rather link answers of the questions to the section in the wiki where the question is answered than to directly answer the question here. This shall support the FHNW lecturers with finding the relevant information faster and should help the team to critically reflect the criteria with regard to the conducted and documented work.

Elicitation and Collaboration

Which stakeholders were involved and why?

The project's stakeholders are introduced in the section Stakeholders.

How did you obtain information from stakeholders?

This information can be found in the section Stakeholders.

How did you communicate with stakeholder?

This information can be found in the section Stakeholders.

Which techniques were applied and what are the experiences?

There were many techniques applied during the project. They can be found within the wiki structure of the three conducted sprints. The highlight were:

  • Map the challenge (story mapping) (Sprint 1 – Understand): This was a great technique to analyse the customer problem and break it down into different levels. Similar to a story map, we broke down the challenge into three layers using the layer "phases", "challenges" and "problem cases". It was great to create the resulting map with the chose methodology as described in the linked section.
  • Crazy 8 (Sprint 1 – Diverge): We used this rapid design technique to draft the first solution approaches based on the identified user challenges. As you can see on the linked page, the results varied immensely what is a huge plus point for this technique. Like that, each team member contributed several of his/her ideas in a very short time. We generated lots of ideas very fast and could use the for the further proceedings.
  • Sticky note voting (Sprint 1 – Decide): A very small and simple technique but very powerful to reach fast decisions in a democratic way.
  • Rapid prototyping (Sprint 1 – Prototype): A first paper prototype was created in a very fast way and based on the drafted solution sketches of the Crazy 8 technique.
  • Scenarios (Sprint 1 – Prototype): A scenario was used to focus the prototype functionalities as well as the test cases on a defined end user journey. Like that, the developer/designer had a clear start, a flow and a clear end of the to be realised functionality.It was very helpful to limit the scope especially at the beginning of such an implementation.
  • Direct unstructured validation (Sprint 1 – Validate): The prototype was directly shown to users and feedback was gathered on an unstructured oral basis. Much feedback could be gathered but the effort to document it and gather actionable insights was high.
  • Direct structured validation (Sprint 2 – Validate, Sprint 3 – Validate): Again was the prototype directly shown to the user but this time a structured feedback form was handed over as well. Still a lot of insights could be collected and the manual effort to analyse it was reduced.

Requirements Lifecycle Management

How were changes to requirements evaluated?

Before a change was accepted, it was first decided if and in what form the change will be accepted for the project setup. This was conducted according to the decision framework (see section Team Space). Changes to requirements were evaluated depending on the state of the item:

  • Item was in Backlog: Change was brought to acting Product Owner and he/she could decide on the specific action
  • Item was in Sprint Backlog: Change was discussed within the team and the acting Product Owner could decide on the specific action
  • Item was in In Progress: Assignee could decide whether implement changes directly or create a new item together with the help of the Product Owner
  • Item was in Done: Product Owner has a look at the change with the Assignee and creates a new item based on the missing functionality

How did you maintain and trace requirements?

We maintained and traced requirements with a Trello board further described in section The Trello Board.

How did you manage the backlog?

Information about how we managed the backlog is also described in section The Trello Board.

Strategy Analysis

How did you analyse current state (stakeholder involvement)?

From the beginning on we tried to include the main stakeholder "the end customer" in our analysis process. How we didi it can be seen in section Sprint 1 – Understand.

How did you define future state?

The future state definition was a team effort conducted on the basis of the analysis insights. You can see this in section Sprint 1 – Diverge and Sprint 1 – Decide.

How was risk assessment done?

Risk assessment is in the responsibility of the Product Owner (see role specification Roles and Functions). Due to the limited time of this project, risk management has a lower priority.

Requirements Analysis and Design Definition

How were requirements specified?

Requirements were added to the backlog whenever they came up from the person who caught them and discussed as well as refined during the Sprint Planning meeting. There was intentionally no use of any description pattern such as User Stories. The goal was to keep the description as easy as possible using a simple "Verb + Noun" combination.

How are requirements prioritised?

Requirements were prioritised in the team during the Sprint Planning meeting and during the remaining time of the project by the Product Owner (see role specification Roles and Functions).

How were requirements validated and verified?

The validation of implemented requirements was first and foremost conducted by potential end customers (see section Sprint 1 – Validate, Sprint 2 – Validate and Sprint 3 – Validate). Furthermore, the initial validation was conducted by the Product Owner and the respective assignee of the task.

Solution Evaluation

How did you assess your (intermediate) solutions?

results were evaluated once by potential end customers (see section Sprint 1 – Validate, Sprint 2 – Validate and Sprint 3 – Validate) as well as by the supervisor stakeholder during the Sprint Review meetings.

How do you explain the result and expenses to your sponsor?

We explained the expenses with a clear mapping to the achieved results and the results with a clear mapping to identified target customer problems and needs.