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

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this 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?

---

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.

---

I'm doing it in the way you have described. I have constraints defined on cards (other color). The constraints are not written in user story format but as a plain sentence like:

• System will support peak usage of 30 users.
• Imports must run daily.
• All filters and search results has to be on the same page.

If customer has some special requirements which are not directly single user story but has broader effect I write them as constraints. These constraints are not estimated and are not part of product backlog. We use them to remind some implementation requirements for real user stories.

---

That was the subject of a talk I saw in January this year at the Architect Factory. I tracked it down. It was Lee Ingram's "Business Driven Architecture: An Example from a Current Startup". I can't find slides, but he spoke about the idea of overarching principles that guide how requirements are to be met.

He had things like multi-tenancy and white-labeling. With a multi-tenant web-service, you have to plan from the beginning for segregation/isolation of users. Similarly, if you want to be able to white-label your service, then many more things need to be configurable (style, labels, etc). Both impact nearly every story.

---

I highly recommend Jeff Patton's presentation on user story mapping.

He not only clarifies the makeup of exactly what purpose stories serve (or whatever you would like to call them), as well as how to build relationships or dependencies between stories, and how to deal with them.

---

This general idea of "principles" (or constraints) seems like a good one. I've seen what happens when things which really should be in this class - e.g "system must achieve some specific, quantified level of performance" - just gets thrown into the backlog and lost amongst all the other "feature" stories: noone worries about performance (because "it's OK... there's a story for that somewhere") and then when someone eventually does pick it up (oddly, these things always get left to last, despite the high value to the customer) they find themselves with an impossible task for the few days a story is expected to take, and likely only really achievable with some serious rearchitecting of the system which should have been done much earlier and now has a massive refitting cost.