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.
Related
I am unfamiliar with the ideas behind creating user stories for Agile projects, as well as acceptance criteria.
I was wondering how I could turn any MVP design, like the Basket MVP, into tested user stories.
What, by my assumption, are below-stories?
Remove Design
Update QTY
Edit Design
Secure Checkout
Chat
Promo Apply
Product Section
For each ticket, how to add requirements, for example:
What are the interactions on the page (e.g. what happens when you
click this button?)
What would different types of users see?
Are there any validations needed?
Are there any error messages / edge cases that need to be catered
for?
Can we break this ticket into smaller pieces?
I'm afraid that the answer to your question is too big to post here.
As well as the pm.stackexchange.com, I suggest buying a book/going on a course.
I could recommend my own but I do not think that is ethical on this forum ;^)
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
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
In my company we have the programmers, front end developers, designers, and UX team all participate in Agile groups. I am no Agile master but I understood that all members of a team should be able to be able to do any of the work. Having designers, the UX team, frond end developers, and sys admins join in on a vote to estimate how long a backend task will take seems crazy to me. I barely know! So my question is am I being too harsh? Can this work in an Agile environment?
You have got the base concept wrong...all members should be able to work across stories. Not total cross-functionality...a developer cannot suddenly emerge to be a UI designer.
And no. of members per team is restricted to 7 -10. So that group should be segmented accordingly.
In my company we have the programmers, front end developers, designers, and UX team all participate in Agile groups. I am no Agile master but I understood that all members of a team should be able to be able to do any of the work.
IMO, this is a misunderstanding. Being a cross-functional team doesn't mean that every person on the team should able to do every job. It means the team should be a right mix of people with the right skills (as a whole) working toward a common goal. In other words, Agile isn't looking for one person with all the skills, Agile is not against specialization. Everyone can't and won't be equally good at everything.
Having designers, the UX team, frond end developers, and sys admins join in on a vote to estimate how long a backend task will take seems crazy to me. I barely know! So my question is am I being too harsh? Can this work in an Agile environment?
First, when using planning poker, nothing says that you need to have convergence at the first round. Actually, I think that having divergences is good, just let people explain why they voted this way, with their certainties and their doubts, and go for next round. Regardless of people expertise area, I bet it won't take more than 3 rounds to find a consensus. Second, after a few iterations, you'll have enough historical data to compare against ("this story is like this one") and this will help a lot, independently of the specialization of team members. Third, as reminded by JeremyMcGee in a comment, team members will get a better understanding of what is going on and of the roles of each other which is another great effect. So, to me, yes, this can work and having different set of skills is a strength, not really a weakness.
The short answer is yes.
Even teams of pure developers will tend to self organize into specialties or owners of specific subsystems (unless you tend to force them to rotate work, but that is a topic for a different issue). Therefore, you will be estimating stories with a significant number of members in the room that have little knowledge of the subsystem work associated with the story.
Story estimation is supposed to be more about comparing scales of complexity/work. It this two times, four times, eight times (or similar scales) more work than defined base point. Or, is it similar to this other item we rated at eight. At least that's the goal. At the sprint level (versus overall backlog), I find teams prefer to estimate with more concrete scales (ie hours).
For people in specific disciplines, you may or may not want them to be included in the estimation process. If those individuals have a reasonable understanding of the complexity of the task, there estimates may be just as good as another member. If not, then they shouldn't provide an estimate.
One benefit of including their estimates as it often creates more outlying estimates (overly high or low). When we have an item with estimates outside of a reasonable envelop, it is a trigger to have a short, but deeper discussion of the work. Often, that discussion forces a group discovery of work/complexity that wasn't obvious from the story description and acceptance criteria.
Agile teams are supposed to be "cross-functional" - i.e. have lots of specialists working together with some overlap.
For web development, and even for IT infrastructure, it can make sense to have a DBA, designers, business analyst, programmers (whatever different skillsets you need) and IT infrastructure people on the same team.
Not all members of the team have to be working on it full time - but any department or specialism that could delay the project or cause misunderstanding by not being involved has to be represented by somebody with enough power or skill to do those actions.
Don't forget to involve people:
who need to sign things off,
people who administer common facilities like DNS, LDAP
network admin
people who buy and maintain hardware,
security people...
I have been involved in projects where the software was ready on time but the DNS or the hardware wasn't - which is a #fail as far as the customer is concerned. What things outside your control are you going to need help with? Team leads, coaches and scrum masters should be looking an iteration or two ahead to get the right people involved.
Getting all the right people involved in estimates and kickoff meetings - including technical sales and the business is critical. Tech sales may think they can't help but often they can answer questions about what the customer wants that can help create a consensus in estimates.
Agile is about cooperation and common sense. That said, I think it will basically boil down to the actual team. Can they cooperate efficiently? If not, you might need to fix it. What does your retrospects tell you? Agile is a path, not the destination
Today with all the mixed technologies that has to work together in a product all developers have to take a wider view how their part interacts with the rest of a product. So getting a team mixed is good I think, but getting the team to talk openly and work together is not always easy. People can be difficult.
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.