Architectural principles as "non-functional" user stories [closed]

Question

I am about to start a pilot project in our company to introduce agile practices, including the use of user stories. After reading two books by Mike Cohn, Agile Estimating and Planning in particular and User Stories Applied, I now have a clearer idea of how to proceed. I have confidence in refining our techniques along with practice.

However there is one thing that does not convince me. In this blog post Mike Cohn defines a specific type of user stories, which he called constraints, which can be used to define the so-called non-functional requirements. Personally I do not like the word constraint and even the use of the classic template "As a ..., I want ..., so that ...".

Rather I will try make the customer to write, always on the cards, perhaps with the above template, those that Nick Rozanski and Eoin Woods called, in their fantastic book Software Systems Architecture, architectural principles:

"An architectural Principle is a statement of belief, approach, or intent that guides the definition of an architecture."

(they also divide these principles into business principles and technology principles, a differentiation I think we should not care of.)

What I would like to do with these principles cards is to put them next to our backlog cards board in order to have them always present during the user stories definition and the planning activities. I would also encourage customers and developers to pick them up and put them next to the iteration board each time they think a card could be useful as a reminder for the team.

Have you ever tried any similar approach? Do you discourage it for any reason? Have you any suggestion on this matter?

Answer 1

Have you ever tried any similar approach? I have not tried something exactly similar but when I was a Scrum Master of my Team we did have a project wide architectural guideline and vision (which all teams were a part of), which we reminded ourselves of, during the various inspect and adapt points of a Sprint and also the Scrum Project, like during Retrospectives, Sprint Planning meetings and even Daily Scrum meetings. Some ways we used to remind us were by adding Done Criterias for tasks which included one principle to follow architectural guidelines, and it could also be added as a small note in Backlogs. In my suggestion below I have mentioned how this was looked at from a really high level.

Do you discourage it for any reason? No not at all. I say your suggestion is good and you should try it for a planning meeting. And as suggested by Ken Schwaber and Jeff Sutherland in their Scrum Guide, you should inspect and adapt during the 3 points in a Sprint - "There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable."

Have you any suggestion on this matter? Is it safe for me to assume that this 'Agile' project in your company is just getting started and you don't have a project solid vision set yet? If yes, I would suggest you arrange a 2 week project wide release planning workshop. The purpose of this workshop would be get all the stakeholders, POs , SMs and Project Managers in single location and develop a Super User Story and Vision, and the rest of the Backlogs broken down from the super User Story.The Super User Story would be the high level vision of the project goal. If you have already done this then please ignore this suggestion BUT my point of bringing this up is that the high level vision or super user story could/should have a part which mentions following the architectural principle set in your company.

Advantages of this? It gets the stakeholder involved in the architectural and technical aspect of the product right from the Super User Story which helps create good understanding of the vision between the business and the technical side, and one cannot live without the other.

I may have intentionally tried to extend the answer beyond the questions scope so that I may get some feedback on my ideas as well.

Thanks, Sid.