Mixing requirements techniques and wrapping them with Kanban.

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

cooking session with light - blend
With motivated colleagues, we are helping other development teams in one large IT organization to improve business analysis and project management. As we meet the diverse teams (from business analysis up to the implementation and production teams) we find various methods of development such as the Unified Process or the V-Model. These proceses have been defined as standard by the management and partly established. Despite that most team are struggling under a long list of high priority requirements and changes, some benefits of the deployed process are visible. It is therefore not an option to replace the established processes with a new agile process.

Instead of replacing your development processe, improve it with Kanban.

This matches the situations described by David Anderson [1]. By establishing a Pull System to limit the work-in-progress and balance the demand against the capacity of the team. The first effect will be to visualize inefficiencies; we can then improve the processes accordingly.

There is logically no predefined way to tailor the existing process with Kanban, since it will depend on where your teams needs an improvement, but in general it makes it easier to

  1. keep the process in place for the overall control of the project, and manage the work load with a pull system,
  2. then use a simpler process for the daily work, Scrum if you like, and also control its flow with Kanban.

At the project / product level, keep the established process as appropriated, to control the flow and add Kanban as pull system.

At the team level use Kanban to drive the work.

You will need to adapt the requirements at all levels (user requirements, product requirements). A possible solution is to apply User Stories and Tasks at the team level and group them into large Use Cases at the project level to understand overall product. Read more on blending Kanban and other processes: Mike Cottmeyer [2]

Key points:

  • You may not need to throw away the established processes – improve them with Kanban
  • Instead of replacing Use Cases with User Stories – apply them at different levels
  • Kanban enables improvements with minimal resistance.
  • Big-bang changes do not work – Kanban enables continuous improvements.

Feel free to comment or discuss your experience about tailoring Kanban and other development processes.

[1] David Anderson – Kanban, Successful Evolutionary Change for Your Technology Business http://agilemanagement.net/index.php/site/kanbanbook/
[2] Mike Cottmeyer – Blending Scrum and Kanban to Create an End-to-End Agile Enterprise, http://www.leadingagile.com/2011/01/blending-scrum-and-kanban-to-create-an-end-to-end-agile-enterprise/

Tracing user stories and code – why is this valuable

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

Establishing and maintaining traceability between the requirements and the product is valuable not only for critical system (and most systems are at least critical for your business) but also for any system that you intend to maintain and improve after their initial deployment. Traceability is often seen as expensive and politically sensitive since agile teams tend to consider that the requirements are not a part of the delivered product. So is tracing them waste?

What is it?
By tracing requirements, I mean tracing the requirements up to the delivered product (software, electronic, mechanic). For example acc. to CMMI [see Ref: CMMI]: Requirements traceability: “A discernable association between requirements and related requirements, implementations, and verifications.”

Why tracing requirements?

  • This is necessary if you consider that the requirements are useful to understand and maintain the product – which is not such a strange idea. There is information in the user stories that is not documented in the code: the “why”, the purpose and value of a specific feature. Losing this information makes it very hard to understand the impact of requirements changes on the product.
  • For complex systems, none of the original developer will remember the original purpose of each part of the product. Keeping a trace to the product requirement does this.
  • It is essential to establish and continuously improve organizational knowledge about the product. Team members can understand the original intend of a specific feature without having to keep asking the lead architect for help.

So – how to do it?

  • Simplify: Define a simple strategy (what is traced with what, on a graph). Trace only what is useful– what you are willing to maintain. Then do it systematically.
  • Automate: don’t try this without some kind of (Requirement Management) tool. In regulated product development, standards require that a product is completely specified. The users’ needs must trace to specifications that define the system required to satisfy those needs. Nothing should have been added or omitted. Requirements management tools are necessary to establish and maintain this level of consistency.

A possible traceability strategy for User Stories: The traceability between the product and the requirements can be supported by keeping a record of the earlier stories, tasks and functional tests. Before establishing new traces, look for what you may already trace without calling it so:

Sample requirements traceability between user stories and the product

  • If you systematically apply the agile practice of writing codes specifically to meet test cases, your product is indirectly traceable to the Stories through the acceptance tests.
  • A Sprint Goal satisfies a set of User Stories. At the end of the Sprint, each Sprint goal is demonstrable by a (potentially shippable) set of features. So these features and stories are indirectly traceable through the sprint goals.
  • For functional requirements, I usually systematically group stories in Use Cases and then trace the Use Cases to product specifications and code.

Depending on your product and teams, many other strategies are possible to do this in an efficient and simple way. Feel free to comment.

References: CMMI for Development, Version 1.3 http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm

Agile Requirements: Expressing Assumptions in User Stories.

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

Last Saturday was cold and I was at home browsing through a pile of unwrapped magazines, so I came across an article by Daniel Jackson about dependable software (see reference below). The author explains the importance of software in safety-critical equipment that we come across every day and he considers approaches that offer a greater trust in them. He defines dependable systems as follows:

“A dependable system is one you can depend on—that is, you can place your trust in it. A rational person or organization only does this with evidence that the system’s benefits far outweigh its risks. Without such evidence, a system cannot be depended on…“

In the development of critical products, we use agile practices like Scrum because they make the product more dependable and safe. In this context, the requirements play an important role.

With Scrum, we can use and adapt User Stories to help to clarify this dependability:

  • First, in Scrum, we formulate requirements in the form of User Stories to enforce verbal communication because talking (and listening carefully), writing and drawing is a more efficient and careful way to communicate.
  • Second, User Stories help us to discuss carefully with the stakeholders the purpose they want to accomplish, the value of a requirement, not the implementation details. For example by using a template like “As a … I want to … so I can ”. This is particularly helpful when testing the system: to know in which context to test it. Example of User Story, in this case the control unit of a medical device:

    As a
    patient, I want a view of the operating history for the last 24 hours in the simplest possible way so I can easily read it in low lightning conditions or when I am tired or confused.Commitments to the details can be postponed and made later when the first implementations and prototypes allow a better understanding. At this time, the constrains (or non-functional requirements) related to User Stories can be written down (just) in time for the implementation and make the requirements quantifiable.
  • Third, for dependable systems, the critical properties of this functionality, and the assumptions that could cause problems -if untrue- could be added to the Story in the same way. When discussing or writing Stories, consider expressing the critical properties and the assumptions, and add them to the Story, for example:Assumptions:
    1) Ambient luminance range: 100 to 1000 lux.
    2) Viewing distance: 20cm to 60cm

    3) For alarm signals, specific requirements shall apply.

Knowing the assumptions and intends of the User Story seems important enough to take the time to clarify this with the Product Owners. For the agile development of dependable products, just-enough details may mean clarifying the value, the constraints, assumptions and risks that make the story verifiable, and doing this at the latest possible time, when the first implemented features permits a better understanding of the product. In this way, we can balance the benefits and the risks, and implement User Stories where we are reasonably sure to understand the risks.

References: D.Jackson, A Direct Path to Dependable Software. CACM.ACM.ORG 04/2009 Vol.52 No. 4 – http://sdg.csail.mit.edu/publications.html