In a new product development project, have you changed your system design to improve its performance at a stage when everything was ready? Have you faced a situation that the system was working well in your environment but once it goes into production it faced many performance or scalability issues? Why that happened because you missed looking at non functional requirements.
When you see the user story “as a user I want to search job using the keyword so that I can find the suitable job” while creating sprint backlog do you consider the non functional requirements of this search feature like the search should be able to give results in 20 Sec and your database may have 10 million records and user can give up to 3 keywords in one go. Will your sprint back log differ if you have to create this search for 10,000 records and 2 min response time? Can by just working on this story you can ensure that you get performance as desired in this requirement? If your architecture does not save the Jobs in a format which facilitates the faster search do you include fixing of that part also in this story?
Usually agile teams that are oriented to deliver incremental products and consider the user stories come up with the major issue of accommodating the non functional requirement. Most of the time these non functional requirements pop up quite ahead in the system development phase.
What is to be done in such cases? Do we need to create an upfront design and architecture keeping in view when the system is finalized it supports all the non functional requirements? This means that we have to anticipate a lot over future needs of the system in advance which may or may not be fruitful at the end. Since, I have come across many cases where team keeps designing and redesigning the system on the basis of non functional requirements and end up delivering low quality offering poor value that hardly lasts long.
First things first, one needs to identify the non functional requirements even before venturing to accommodate the same into the product development phase. Now here is the wisdom- Newkirk and Martin (2001) introduced an innovative practice. One needs to annotate a story card with “Constraint” marked on it and user stories are required to obey and not implement it. This way keep identifying non functional requirements and make constraint cards for all. Let’s check out some examples:
Of course adding constraint card and ensuring user stories obedience to it simplifies things somewhat however, this may slow down the implementation of user stories. User stories get implemented little slower than usual. How to prioritize them? Can these ‘constraints be implemented right from the onset? If yes, then is it not the violation of the principle- “do the simplest thing which can possibly work?” Who would make the constraints? Is it the product owner?
These and many other doubts keep flooding in and the replies may not even be straight forward ones too. Constraint varies from project to project. Every project team is required to predefine a moment for the identification of constraint cards and one should consider that while doing so at a later stage may have an impact on all of the developed user stories.
The question why not put constraint from the beginning- it is because one might need certain features of the system in working condition before you place a constraint on them. Though, for such special conditions, it is recommended to seek out a separate story other than the current one in use and implement a constraint on it. Yet, you are required to keep a last feasible point in the entire project from where on you can start implementing constraints to all of the user stories.
By now, you must have gathered enough footnotes on what constraint is all about. But, do we know who writes the ‘constraint’ cards? Log in back to have a chit-chat over it…
No Trainings found
