1. I come from a use-case background. Stories look a lot like use-cases. Does it make sense to just write them out the way I would a use-case? Or am I missing something?
2. Printing? I would need to give a hard copy or at least a PDF of the stories to the client. That is an absolute requirement. Can I print this from TeamPulse? If not, would I be able to find the information in the database without too much trouble so I could make my own report?
3. How do you use this to capture software requirements that are not 'stories'? i.e. Architecture, "The application will be developed with ASP.Net and use a SQL Server database." There are many requirements that are like that.
Note: we are not using TFS yet so this would be used as stand alone.
Thanks
6 Answers, 1 is accepted
Thank you for the questions, I will do my best to answer them for you:
1. While User Stories and Use Cases are similar, there are some differences. A user story often takes the form of a single sentance or very small paragraph, whereas a Use Case is much more formalized. Furthermore, a Use Case generally discusses implementation details that a User Story will not go into. The following link has a pretty decent comparison of the two that I think might help you decide how you'd like to approach entering your stories into TeamPulse: http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/
2. Our upcoming Service Pack release will be including the newly released Telerik Rich Text Editor control, which will provide a much broader depth of editing capabilities than our current implementation. Printing will also be included with this, via a button in the ribbon.
3. As described a bit above, user stories don't generally imply implementation details, but this is where tasks can often be used to help provide that information. For example, if your story is "Customer details can be persisted for later retrieval", when you decompose that story into tasks you may have tasks such as "Create SQL Server database schema for Customer data" and "Develop data persistence service for customer objects". You may then further decompose those tasks into lower levels of granularity as well, if you wish.
Best wishes,
David Harris
the Telerik team
Rank 1
2. OK. Have to ask, when will it be out?
3. Don't think this will suffice. I'm OK with adding those things as tasks, but they are high level requirements and need to be visible at that level, not just buried down in tasks. That's why we consider use-case documents to be incomplete without a high level architecture or requirements doc.
Unfortunately I cannot give you a date on the Service Pack release at this time. It is in the final stages of testing and we expect it 'soon', but I cannot tell you anything more specific than that.
Thank you for the feedback regarding system-level requirements. I am adding the feedback into our internal systems for review and we will discuss possible methods for distinguishing these items in future releases. I have assigned you some Telerik points for this important feedback.
Regards,
David Harris
the Telerik team
Rank 1
I am not sure if it is ok to answer to an old subject, but here what I’ll try in regard to question 3, requirements who are not stories. Be warned that is probably not “orthodox” agile programming.
I added, in various projects, some “personas” who are developers. In fact, it could make sense to have a software developer as user persona, as we could sell some API to developers. But in fact the persona represents internal developers, in our company.
So, we can target some requirements (stories, but also ideas) to developers; and have stories like: “As a software developer, I need an ASP Net portal” and so on. Like conventional user stories, we will have a broad story and several substories (by example I need an architecture layer who does xxxxx so I can yyyy), and a substories for the precise requirement of the layer).
Hope it helps.
Richard
I'm glad that you still looking at TeamPulse. From the previous post we introduce a lot new features that can help you with the customization of TeamPulse in your process. We introduce tags, backlog, customizable views. In your case you can use hierarchy of stories. During every release we have a few big stories and we call them epics (we add tag epic to them). During the release we go in more details about every epic and create a child story to it. In those child stories we add the task for development.
Our long term vision is to make TeamPulse more customizable so instead of User Stories you can call them Use Cases and so on. We want people to use TeamPulse in the most convenient ways for their cases.
Jordan
the Telerik team
Join us for the Portal Release Webinar and be among the first to see it.
Reserve a seat today!
Rank 1
Hi Jordan, and thanks for your answer. Yes, I saw the hierarchy of stories, and it is a great feature. Still, we’ll stick with the “dev” persona, as it is useful for requirements who will affect a lot of users stories. In short, the “dev” persona allows us to track requirements like API or tools that will be used by several stories but are not functions of the stories, just tools.
Richard
PS. thanks for the "pic" tip.