Related
My understanding of BDD is that one describes a system in user stories and then developers take those user stories and turn them into an application with the intention of adding real business value with every 'sprint' (period of software development). The result (as far as I can tell) is that the domain model emerges from the user stories throughout the development process. That is, after the first 'sprint' much of the domain model will not have been designed.
My understanding of DDD is that software development continues with reference to a full domain model, albeit an evolving one. In DDD the model is expected to change, but it is nonetheless 'complete' at all times.
This seems to be a fundamental difference between the two approaches. How have people handled this?
BDD done well does not produce a "complete" model. There's a reason that Dan North, the guy who came up with BDD, calls his blog "embracing uncertainty".
I find it useful these days to think of three kinds of things that we can analyze: the known, the knowable and the unknowable.
Known stuff is simple - for instance, logging in. It's well understood. We don't need to talk through the scenarios.
Knowable stuff is usually related to the domain, or to something that has been done before. This is a great place to do BDD, because it helps transfer knowledge - including the domain model - from the business to the developers. Talking through scenarios is a great way to understand stories better. It can also help us to find scenarios we've missed. Chris Matts, who's the analyst who helped put the "Given" in "Given, When, Then" calls this "breaking the model". He actually offered prizes for anyone who could come up with a scenario that wasn't covered in his model, which he uses scenarios to define and refine.
There's also the unknowable stuff. This happens whenever we're working on something new, or something we've never done before, or something in which nobody has expertise. You can tell if you're in this place because business people will start reacting with surprise when you come up with the scenarios they haven't thought of. BDD is a really great way of finding these places, but at this point you probably want to stop trying to nail down the scenarios and just try something out and get feedback instead. Your domain model, and your user stories, and your scenarios, will all gradually emerge (see the complex domain in the Cynefin model).
I know a lot of teams use BDD as a way of apparently eliminating this uncertainty. You can't eliminate it. You can only hide it until later, when the feedback from delivery comes back to bite you.
With respect to DDD, when we do it with BDD we tend to focus on those parts of the domain model that are relevant to the scenarios we're working on, though we might have an idea of the larger domain model overall. If you're using Feature Injection together with BDD you'll already have talked through most of the capabilities of the system, especially the new ones, so you'll have an idea of what kind of things are in the domain. Evolution and all other rules still apply. BDD and DDD work really, really well together, with conversations around scenarios helping to bring out the domain language. They are not fundamentally different, but completely supportive and compatible.
Please also read the answer I gave to this similar question, which features a video of Dan North and myself talking about this very topic.
I would include user stories, DDD and BDD as they are very very dependent of each other. I tried to summarise the link here: http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/
I hope this picture is both simple and rich enough to explain the link between these "concepts"
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
The Product owners have specific requirements around how the Product should enable the users in a complex business process workflow (approvals and what not). The easiest way to document the requirement is in the form of a process diagram/flowchart.
In Scrum however, it is advised for requirements to be in the form of user stories. What is the best way to approach this?
Option 1
Have generic user stories that encompass the workflow, and attach the flowchart diagram as a supporting document. e.g. As an author, I want to be able to submit my article for approval process so that it will get published.
Pros
it's easier for people to understand and digest - rather than reading 10-20 user stories.
Cons
it becomes an epic
Option 2 Break down the complex flowchart into its own user stories. e.g.
As an author, I want to be able to submit my article.
As an editor, I would like to get notified when an article has been submitted so that I can review it.
As an editor, I need to approve an article
As an editor, I would like to be able to request for more information
...
Pros
pure Scrum. easy to prioritize/estimate/plan
Cons
As you can see even a short business process workflow will easily explode into a lot of user stories.
I agree with pma_. Do what makes sense. In this case, you have some great looking user stories.
"As an editor, I would like to get notified when an article has been submitted so that I can review it."
If you have a ton of these, then perhaps they are too small. They would all be 1-2hrs. That's probably not a good thing to have. In that case, try grouping them. Perhaps
"As an editor, I want to be able to manage articles". That would include several of the ones you have already.
Keep in mind the goals of user stories...
Track items on a burndown chart
Deliver fully functional work (not an unusable subset of work)
Have estimatable portions
If you can achieve those goals, you're good. If not, try again.
Oh, and one last thing - keep the flow diagram, don't throw it out in favor of stories. But supplement the stories with it.
If this business workflow is like most business workflows, each of those steps will have a significant number of rules. Those rules should map into acceptance criteria for those stories and ideally, automated tests to prove that the code works as intended. Because of the potential for a lot of acceptance criteria, I would lean towards the second option.
I tend to go towards Features/Epics early on with the core end user/stakeholder value-adding functionality, such as in your example to "Publish an article so that the subscribers can get the latest news". Then once the Feature is getting closer to implementation I'll split it into implementation sized stories if needed.
Most non-trivial business workflows benefit from being split up during implementation so that they can be continiously deployed and verified in order to get early feedback from the stakeholders. The big con of having everything as one big bang implementation is late validation. I think that having early feedback is outweighing the increased administrative burden of handling multiple stories.
A tip on how to split epics into stories: Lasse Koskela has a great writeup on how to split stories in different ways.
For me all agile is about using common sense. I this case you have perfect desing so just implement one and don't look for unecessary things.
We're currently building a business process based content management system. We split our processes into stories as per your 2nd option.
But, of course, we keep the flow diagram handy. In fact, we print it out and stick it to the wall. We even keep every old version of it so we've our own paper based version control stuck to our wall (in addition to using git for the electronic version ;-) )
In Scrum however, it is advised for requirements to be in the form of user stories. What is the best way to approach this?
The two options that you have mentioned are not really options, they are sequential stages, IMHO. During Agile Requirements Gathering or Product Planning the first step is to create EPIC stories. After you have those Epics, you need to break them down into smaller chunks.
Without the EPICs you will most likely to run into the issue of creating random stories without getting a grasp on the sense of belonging of a story. You can in a way create a hierarchy in User Stories. Without understanding that, everything is just random, hence it makes it tougher to wrap your head around or manage the stories as a PO.
Offcourse there is much more to all this than what I mentioned in the above paragraph. That's why probably you need an experienced Scrum Coach or do a lot of diligent reading/implementing on Agile Planning and User Story writing.
Hope this makes sense. I would suggest reading Agile Estimating and Planning by Mike Cohn for anyone who even remotely thinks of taking up a PO role. Best of Luck!
Workflows are an interesting entry to writing user stories and epics, but user stories don't map to work flows, they map to business capabilities. So you are incorporating some fallacious thinking from the start in this question. Workflows are a good tool for the conversation, but will live independently of workflow as they are about functionality, not timing. Timing lives in the business rules.
On that note, business rules are not Acceptance Criteria, they are the connection between Acceptance Criteria, which are features that can be demonstrated by a product owner, and Test Cases. Again, Acceptance Criteria are about features, not behavior. Behavior lives in the business rules.
For instance I might have User Story for an ATM that says "As a user, I can check my account balance." And the Acceptance Criteria could be "If I am overdrafted, I get an alert notice." The rules for what constitutes an over draft (I had $1000 in my account and deposited my $2500 pay check, but that won't clear before my $1500 mortgage payment, etc.) are not acceptance criteria. They are business rules whose execution results in the demonstrable action of the Acceptance Criteria. Note, that this user story could be captured through a workflow analysis, but might live in many workflows (or none).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I'm starting a project with a team and we're using SCRUM as methodology. It's my first time with SCRUM. We have listed our functionalities and we made our stories, (user stories and technical stories as well as their tasks).
I've a tight UML approach to start any dev project and for me, after listing all the functionalities, the next step is to make the User Cases Diagram to let everybody see what's the application going to do and who's gonna interact with it. But my team said that there's no interest in using UML in SCRUM.
Can I use the User Diagram of UML to represent the User Stories in SCRUM? Which other diagrams can be used in SCRUM? (It could be a stupid question 'cause I cannot imagine an application without a class Diagram or a Sequence Diagram, but I really wanna see the advice from the experts in SCRUM)
Thanks.
Can I use the User Diagram of UML to represent the User Stories in SCRUM?
A use case diagram would be helpful, because it is pretty straightforward, and gives a high level idea what the project is about.
However I won't recommend to use any other UML diagram in scrum. I agree with the others that in an agile project the code changes so frequently that your diagrams will be obsolete after several days. In this case you have to redraw them, which is a waste.
For example if you are using eclipse for development, a simple refactoring step can ruin your class diagram :-(
Which other diagrams can be used in SCRUM?
I would suggest to use mindmaps. Recently we started to create our own user stories with drawing large mindmaps and put them on the office walls.
We have a feature in the middle, and we connect sub user stories to it - and sub-sub user stories to them -, and every available information we have at the moment. With this approach we have everything in one place: user stories, technical informations, questions, etc.
Of course the mindmap grows day by day, and we know more and more about the feature we have to implement.
Actually we are doing something similar described in this agile dzone article, but since you are using scrum not xp+kanban I talked about user stories not MMFs.
You can use whatever you like in Scrum that helps your team communicate effectively. Scrum makes no decisions, judgements, or guidance on what tools are effective for that team. It only asks that you reflect on the tools and practices used in executing a Sprint and make adjustments accordingly. This is the inspect and adapt loop.
Being open and honest in discussing the benefit of the tools and techniques used to deliver value requires a lot of effort and willingness by the individual members to be open to change.
What I've been told from people who've been using Scrum for a while (ie: this is opinion) is that doing UML diagrams can be a bit time consuming because as your development methodology is agile, your requirements could very easily radically change after the first sprint's show-and-tell, which means you could be doing fairly big redesigns.
Of course, do scratch up how you will tackle your tasks in the sprint backlog - you could certainly document as you go, but maintaining a central repository of class diagrams, etc. could be a slight waste in resources.
I'm not sure what's your role in the project, I'm supposing you are the PO. In that case, use additional documentation if it makes sense. Consider a user story as a reminder for the team to have a conversation with the PO about it.
If you think the user case diagram will clarify the functionality you are asking for, the it's ok. In fact, place it on the wall beside the scrumboard and burndown chart.
In my experience it is sufficient to specify for each story a "how to test" scenario. For example, suppose I have a story for Stackoverflow:
"As a user I can post a new question"
The "how to test" scenario could be:
"Click on a 'Ask Question' button, a form is displayed with a textarea for the question text and a textfield for tags. After the user enters both -they are mandatory- the user is redirected to the question list. The user can see the question title in the list, along with the tags"
So maybe a use case diagram is not really needed. I would recommend to try the "how to test" and see how it goes. It is very useful for the team because they know what you are expecting from the story, from a functional point of view. And you won't be doing documentation for every story.
If you don't like it, the go with the use case diagram, but it is a good idea to give the team something more than the story description.
Now, about the technical stories you mention. What are they? Why is a technical requirement mixed with the functional requirements? Maybe it IS a real requirement for the project, but usually it is not, and can be rewritten as a functional story. Unless your product is something like a framework or library.
For example, the technical story "create indices for the 'get questions' query" could be rewritten as "speed up the questions list page".
I only use class and sequence diagrams with Scrum because these two diagrams are live synchronized with the java code.
I certainly don't create UseCase or other diagrams or even try to generate code from diagram (e.g. MDD) because as soon as something is changed in my project and my code it is really too painful to update my diagrams. Diagrams should be automatically updated without any human intervention. I did many project with Omondo EclipseUML and it worked really well.
SCRUM is a application lifecycle management framework, not a methodology as you stated. Please refer to scrum.org
Use Cases are abstracted. If they help your team during refinement, then great. BUT once your team has committed to the story, change is welcomed and there is little point maintaining them once the story is done. The goal is always user acceptable working software!
UML state machine diagrams are useful in Scrum for projects focused on redesigning UI while retaining business logic:
State machine modeling is a dynamic modeling technique, one that focuses on identifying the behavior within your system-in this case, behavior specific to the instances of a single class. My style is to draw one or more state machine diagrams when a class exhibits different behavior depending on its state. For example, the Address class is fairly simple, representing data you will display and manipulate in your system. Seminar objects, on the other hand, are fairly complex, and therefore it makes sense to create a state machine diagram for them.
References
UML 2 State Machine Diagrams: An Agile Introduction
I am working on a product and I am using Pivotal Tracker to write user stories, but I am quite new to BDD and XP, and newer to Cucumber. So I am getting confused by the terminology a little bit. What is the difference between a story and a cucumber feature? Both are simple descriptions consisting of three parts--actor, action and business value. Right? So if I already have a story written in Pivotal Tracker, should I just copy that directly into the Cucumber feature? Can one story have multiple features?
What do you think?
A feature is a fully-fledged piece of functionality, ready to go live. For instance, a feature might be a user profile, complete with registration page, validation, pictures, etc.
In BDD-terminology, a story is a small slice through the feature which is functional, and on which we can get feedback. For instance, we might produce the registration without a profile page, and without validation. Validation might be another story. Pictures can be another.
It can take weeks to produce some of the more complex features, taking into account architecture, new technologies, domain learning, etc. - so a story lets us get feedback more quickly than this.
You might be interested in learning about Feature Injection - BDD in the analysis space. We use the template quite a lot for both stories and features:
In order to <achieve a goal>
As <the stakeholder who wants the goal>
I want <something>
I tend not to worry too much about whether what I'm doing is a feature or a story, as long as I'm getting feedback as quickly as possible.
"Story" is a series of development tasks which together accomplish a goal. It is a device used by developers.
"Feature" is, well, a feature that the business stake holders want to see in their application. To implement a feature you might need one story, or many, since typically if a story is "too big" it is broken down into more manageable smaller stories.
BDD is a variant on TDD (Test Driven Development). As I understand it, the semantics of BDD are less implementation oriented than the semantics of TDD, in that you use phrases such as 'the system should load the user' instead of "the user instance should not be null after being loaded by the DAO" -- they describe system behavior (feature set) as opposed to specific details of the actual implementation. In the end though, they all test the same thing if done correctly.
And, on topic, the concept of story is really orthogonal to BDD; there are development practices that have Stories and do not have BDD.
Unfortunately feature is a heavily overloaded word in this space and a Cucumber feature is a very different thing to a fully fledged piece of functionality.
The most interesting difference between a 'Cucumber Feature' and a User Story is that a User Story is a historical document, whilst a Feature describes the current state of the application (assuming the feature has been implemented).
This difference is (IMO) much more important than differences in granularity or size. You can have a Cucumber feature that was driven/inspired by many user stories, and you can have a single user story that has many Cucumber features.
Once a Cucumber feature can be run it is code. This means it is much more prone to being refactored and changed. Each time you run it, it gives you information about the current state of your application. A user story tells you about what your application should do. Or perhaps more accurately, what the authors of the story thought you application should do at the time the story was written.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
The book User Stories Applied contains single page discussing Personas. The definition of persona from the book is:
A persona is imaginary representation
of a user role.
It futher discuss definition of the persona:
Creating personas requires more than
just adding a name to a user role. A
persona should be described
sufficiently that everyone on the team
feels like they know the persona.
It also recommends to find a photo on Internet or in magazine and use this photo for persona so that everybody can clearly imagine persona working with the application.
Ok. All these ideas sound good. It can be fun to define personas to user roles but is it worth it? Is there any real or measurable quality or increased efficiency when using them?
Do you have any good examples where personas really help the development team? Do you use personas in user stories?
Edit:
I have found nice article about personas in MSDN.
This can helps when there is lot of roles and when they are very complex.
The more roles you have, the more complex it is to satisfy all of them. They have different needs, values, power, etc. Having the picture sounds a bit trivial, but it really helps too.
Check this really nice video from Jeff Patton on the subject: http://www.infoq.com/presentations/pragmatic-personas
His website: http://www.agileproductdesign.com/
The reason for using personas is for the team to get a better understanding of the story. It makes it easier for the team (programmers...) to relate to the story on a more personal/emotional level, which I think is good.
If your team has a habit of shipping stories that are not what the customer wanted, then by all means, try the persona approach and see how it works out for you.
Inspect and adapt, as usual.
Personas can be useful also to make communication between development team and business more clear. When you speak more in non-technical terms business might understand you more clearly.
Instead of the description
The application administrator will maintain the db structure and the application code
you will use persona Frank:
Frank is responsible for technical issues of our application. He understands the database. He does not teach the users how to work with the application but in case of any problems he can solve them.
I still am not sure whether to describe personas with real emotions, e.g. "Frank is not very happy to help the users all the time so the users should not disturb him often".
I can remember reading a Boston Consulting Group white paper on personas in the growing latin american middle class. While interesting, I thought their level of scrutiny was wholly unnecessary. Personally I think personas are a waste of time and should be viewed as an ancillary tool, and not a priority objective. I remember spending a week constructing personas for a social network for entrepreneurs. Big waste! I think it is better to discover your company or website mission. A company mission can help you rationalize how to best service your users, irrespective of their particular personalities. Think Facebook, "We want to allow users to share and connect with their friends " or Foursquare " We are the social utility that connects users to their cities."
On the other hand, you could have Persona "Petr".
"Petr likes to drink lots of beer. Petr only uses his computer when he is drunk. Petr's requirements depend on his blood alcohol level. Petr likes to program his computer. His best code is written after 12 litres of Pilsner, and he doesn't write code unless he has consumed at least 6 litres of Pilsner. "
What producing Personas does is help the analysts really understand what they are writing about. It helps you discover requirements you would normally overlook.