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 understand that agile user stories are for human stakeholders for an app, product; but what if you're making a game (ie: tycoon) where you have AI characters performing actions or third-party entities that interact with the human player.
Do these entities have their own stories?
IE:
As a popcorn vendor I want to be able to ...
As a football shirt sponsor I want to be able to promote my product to last years Champions League Winner
Or am I overcomplicating it?
Thanks
Interesting question but consider the following two points:
A user story is a brief description of a features our customer would want in his software
Business people (of our customer) and developer team must work together daily through the project
So AI characters:
are really your actual customer?
can work daily with you?
Even if you are working on the "tycoon engine" AI characters interact with, so AI might be considered as your customer, I don't think they can work daily with you,maybe one day with some limitation.
The main objective of any good user stories is define the work and most importantly defines the value of that work.
So whatever situation it is, you will define user stories where the value is driven from the Business. In case of AI, if you believe that AI is running Business and Business is giving you money to build values then you should listen AI. Otherwise listen to whomsoever who is feeding you money (i.e. sponsoring your project).
In terms of entity, yes, AI can be an entity but at the end he has to interact with you and define these user stories. Of course Artificial Intelligence cannot do you for you. So someone is thinking on the behalf of AI.
Thus you can use AI as persona
What is persona?
A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. For the bank, potential personas could be named Frances Miller and Ross Williams. In other words, personas represent fictitious people which are based on your knowledge of real users. - See more at: http://www.agilemodeling.com/artifacts/personas.htm#sthash.7ndZPbDx.dpuf
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm stuck with one small part of my project. The main idea of the project is:
There are a customer, a bank and a shop as actors.
A customer wants to make an order but before he/she does it, the bank needs to check if the customer is on a blacklist.
If he/she is not, the bank puts the customer's and shop's details in a file and at the same time sends a credit note to the shop.
The next part makes me confused:
Customer personal information should
be protected following the General Data Protection Regulation
(General Data Protection Regulation - GDPR).
How can I implement this part in my diagram?
First of all, the use-case diagram is about user-goals. Use-case diagrams do not describe an order of what happens. So "before", "after", "at the same time" do have no effect on the diagram. If you're interested in the sequence of events, you should consider an activity diagram (i.e. flow of actions) or a sequence diagram (scenario).
So what I understand from your narrative is that:
actor User, in relation with the actor Shop (but is it really an actor?) has a use-case Order something
actor Shop (but is it really an acor or does your system ensure this?), in relation with the actor Bank has a use-case Control payment (make sure that the customer is not a known terrorist and ensure also that the customer has the money needed, probably in relation with the customer's bank).
The information you provide si probably very incomplete, so I leave you as an exercise the precise design of the use-case.
THe GDPR requirements do not influence at all your use-case model: it does not change the gloals, and it does not change the involved parties.
What might be influenced is the activity diagram and the class diagram:
the GDPR requires among others a privacy by design. So you cannot provide to the bank details that they do not need to know (e.g. what the customer purchased).
the shop is not allowed to get the blacklist either! The control of the blacklist is done by banks, so that the shop owner will not be tempted to refuse a sale just because of some similar naming.
THe only thing that could eventually influence your process, is the consent. Giving the consent and managing privacy could be a separate use-case, since its's a right given by the law and that some users want to exert. For example that the customer consents that his/her data is provided to another party. But in your case, it doesn't seem a big deal: in the case of a payment by the bank, this seems an obligation and the blacklist is in general a legal obligation not related to the the consent. So it will not impact your design, but only the wording of your privacy statement. So it seems that for you, GDPR will be more a legal matter to check with a legal expert, than an engineering one.
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.
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
If I divide development of a particular feature into multiple stories:
First one for a high level design of the feature,
Based on first story I create other stories to develop the different stand-alone pieces that compose the feature,
Does it mean I'm doing waterfall?
Furthermore - if I divide development of the previously identified stand-alone pieces into design and implementation.
Would that mean that I'm doing waterfall?
Note: I am big time Scrum novice.
There is no such thing as design and implementation stories, User Stories should provide some level of end-to-end functionality to the user (i.e. delivering customer value).
The fact that you are mixing the terms stories and features doesn't help to communicate but what you're describing sounds actually like tasks (Sprint Backlog level), not user stories (Product Backlog level).
And if they are not tasks, then they are very bad stories. Maybe the "functionality" is too big and you should put the story on diet but what I see here is a typical story smell.
If you are new to User Stories, I strongly recommend to use the regular template (As a <type of user>, I want <some goal> so that <some reason>) and also to follow the INVEST model. This will really help you to avoid pitfalls like the one of your question.
Back to the real question (Am I doing waterfall?): there is nothing wrong with doing so design inside a Sprint (as a task of a story). But if your whole story is about design, you're not really doing Scrum, you are supposed to deliver a demonstrable end-to-end increment at the end of the Sprint.
Scrum stories tend to be about "business value":
Business value is a concept that describes the relative worth of any development effort to the business. Business value is often unquantifiable, but often relates to money.
You can think of business value as something that could still be sold if the project was stopped.
If you write a story to create: "a high level design of the feature", what you would produce by implementing that story isn't something that the business can sell. It's not something customers can try, buy, use. In effect, the business value of that story is zero.
You might have better luck thinking about stories "vertically". "Vertical slices" are minimal features that cover your entire technology stack. For example: "A user should be able to enter their name in a text box, click a button, and be shown their record in the database." It's not, by itself, especially useful, but it is more valuable than a feature design.
No, you're not. The sub tasks can be added to the backlog (presumably with roughly equal priority so they come out around the same time) and then the super-task would be to integrate/test/etc the separate components.
It sounds like a valid way to breakdown a large component to me. Just make sure you size up the different chunks appropriately. I've found 4-16 hour chunks work best. Giving 40 hours for a task means they'll do 2 hours of work until Friday when they cram the other 32 in (along with lots of bugs).
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
Should technical items such as "Upgrade sever from v1 to v2" or "Increase startup performance" or "Refactor login module to reduce code complexity" go in to the product backlog and if so how should a non technical product owner be able to prioritize them v.s other more functional backlog items?
Should there be a separate backlog for technical stuff? Should we have a joint PO role with two persons that could prioritize functional and technical stuff on the product backlog?
Usually in the 'vanilla' SCRUM the technical tasks you mentioned will not go as separate stories.
To me the non-technical PO should not be looking at the stories like 'Upgrade the server'. It's not a business story, it is not visible to the end-user so it is difficult to prioritize if it is formulated this way. Priorities should be assigned according to the business value of the work. 'Upgrading' does not mean much. 'Allowing more simultaneous connections', 'Reducing the downtime' or even 'improving the team velocity' might provide much more valuable insight to a non-technical person. If you cannot find a non-technical description ask yourself a question about the necessity of the upgrade :)
The 'refactoring' story is even more complicated. Did you ask yourself why is it a story at all? Refactoring could be done as a task in the story but it is rarely a story on itself. So if you want to make login work better or provide more features that's a story but tinkering under the hood does not count as one. Please also note that refactoring without a business purpose could easily lead to a so-called 'gold plating'
I would suggest doing the 'upgrade' stories as a spike with the 'improve performance' and 're-factor' being the tasks for a relevant business story.
P.S. You might find a good discussion on this topic (mostly in part 3 of it) in the excellent book by Mike Cohn called "User Stories Applied: For Agile Software Development".
I agree with the view of looking at the business benefit of any technical story and tracking it on the main product backlog
I do think that there are internal stories related to the velocity/capability of the team, which are sometimes more conveniently managed by assigning some capacity to the developers, especially when the Product Owner is not interested to prioritize or manage those stories.
E.g. assign 10% capacity to test automation backlog (of legacy regression), CI server setup, etc.
Yes, everything can certainly be expressed in business terms, but some of it should be considered "the way we need to do our job" where there is trust between Product Owner and team that the team will make best use of the capacity assigned for this.
I have had success with the dual backlog approach:
Product backlog is owned by the product owner. It contains story-level items (features) that get estimated by the team and then prioritized by the product owner. This estimation process splits the stories in smaller tasks.
Team backlog is owned by the development team. It contains task-level items that are relatively small (can be completed within a sprint). They can be linked to stories for example as impediments: to complete the story, the following technical tasks have to be completed first. They can also be independent so that they are not required for any story per se but they pay back some technical debt to enable higher velocity in the future.
(On some large, multi-project programs I've also had program backlogs that contain epic-level items, owned and prioritized by a program management team, to be split to stories into product backlogs further on.)
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
My company has tried to adopt the scrum methodology with mixed success. Theses are some areas where we've had issues. How do you handle these?
Tracking requirements from
Product Marketing through to product. We're trying out JIRA to track all requirements individually and assigning a release to each one as it is picked for implementation.
Who creates stories? Product
Management who doesn't know enough
to create effectively small stories,
developers who may not have domain
knowledge, an analyst in between?
Functional specs
do you write them or just try to get them into a story
definition?
Do you write functional
specs per story? Per feature?
How do you see the relationship between functional specs and stories?
answering the question from people
with VP in their title "what are we
going to get by [8 months from
now]?"
Let's see if my take adds anything (not certain by any means...)
I'm not sure about the "assigning a release to each one" thing. I thought the idea was to put a "price" on each story/function point/unit of development and pick what goes into the current sprint. Everything else is backlog - you can offer some indication of remaining effort (see evidence based scheduling in FogBugz) but I don't think you should be allocating to specific sprints - you don't know what'll be in the backlog by the time you get there, for one thing. All you know is that it's going to change, so why waste time on it?
There should be a designated user representative. Or more than one, if domain knowledge can't be concentrated in one individual. But someone from the business domain should be in charge overall of deciding what goes into a sprint, subject to the effort available, of course. There can be a place for a Business Analyst type, but they need to be domain experts. If your user(s) can't write stories, even with your help (it's a co-operative thing, or should be) then you all need help. Consider getting a coach involved for a sprint or two.
You won't be writing functional specs in an Agile environment. You'll be writing code. Your user will be on hand at all times (or you're already exposed to significant risk) and they're your spec. The story tells you "what", and is going to be a small enough unit of work that you should be able to decide on "how" fairly quickly. And refactor. Always refactor. It's not an overhead, it's part of the process and your design won't evolve satisfactorily without it.
If you have VPs (hey, I'm a VP, we're not all bad!) who ask that sort of question, then parts of your company are not getting it yet. Choose someone (the person best able to deal with non-techies, perhaps, or maybe the person least able, since they clearly need the practice) to explain it to them. If what's built is important to them, perhaps their questions are an indication that someone's not as involved as they should be.
You should translate your requirements into a Product Backlog. This backlog is what you use to decide what Sprint Backlog items are chosen for each Sprint iteration. Management decides what is on the Product Backlog, but the team needs to agree to what they can produce in the Sprint (this is a negotiation that occurs at every sprint).
Your Product Owner (usually a product manager) drives the creation of the stories. The Stories are simple (as a system admin, I need to be able to add a user). If your product management does not understand your product, you are in trouble.
Agile is about designing as required. The design is never in the story. The spec can be per story, or per feature. You could design all your CRUD inside of one spec, which covers multiple stories.
The Product Owner gets a product demo at the end of every Sprint. So value is demonstrated at every cycle. So your VP would get reports on a monthly basis (ususally 3 weeks of dev + 1 week to prepare for the Sprint demo).
If you are going to do anything in regards writing or designing code, one of the things you should always do, is write a spec, irrespective of whatever methodology you are using, wether it is Scrum, XP, Agile or SDLC. Many people who say that writing specs is so unagile and a monument to wasteful bureaucratic paperwork. The simple fact is that they are misguided when they say that code is the spec.
The clear fact is that a spec allows you to formulate your ideas and designs beforehand, and its much easier to change a spec than it is to change a program, especially if you are working outside the confines of simple LOB application. Specs ensure you have a clearer understanding of what is required when you start coding.
Its been show time and time again that teams that use specs, design better software.
In my opinion, if you hear anybody say the code is the spec, that is dogma, plain and simple, and is storing up huge maintainability problems for the future.
As an aside, I don't have anything against the Agile Manifesto or light management process centric methods like Scrum. I've used it in the past few years a number of times,
and it delivers. I've also seen good software down the drain, where an agile focus would have saved it. But it is no panacea or silver bullet.