User Story là gì trong luyện thi PMP PMI-ACP
User Story là những yêu cầu của người dùng, thông thường được ghi nhận dưới dạng những câu chuyện được cắt nhỏ từ những Business functionality. Thông thường cấu trúc của User story như sau:
User stories must provide values to customer and be INVEST:
- Independent – user stories can be re-prioritize and developed in any order.
- Negotiable – can be negotiated between project dev team and customer.
- Valuable – can add value to the project
- Estimable – can be estimated for the efforts involved
- Small – keep user stories small, ie: between 0.5-10 days
- Testable – can be tested to confirm completion.
User stories is preferable if it impacts all architectural layers of the systems:
- Presentation layer
- Validation layer
- Business layer
- Database layer
Trong đề thi PMP, PMI-ACP có thể hỏi bạn User Story sử dụng để làm gì?
Question: The main purpose of writing a user story is:
a. To document features and functions required by stakeholders
b. To communicate progress
c. To record the list of issues encountered on the project
d. To perform what-if analysis
Đáp án là A: User story dùng để biết về những tính năng, chức năng yêu cầu bởi stakeholder.
User story thường được sử dụng trong bộ công cụ Facilitated workshop, đây là bộ công cụ mời tất cả stakeholder có liên quan để trao đổi và nghe những yêu cầu, mong muốn của họ thông qua user story.
Ví dụ: Với vai trò là người quản trị Contact Center tôi cần tính năng tập trung hóa quản lý để không phải di chuyển giữa nhiều cửa sổ (Unified User Interface).
USER STORY’S FAQ
What is a User Story?
A user story in Agile software development is used to capture a description of a software feature from an end user’s perspective. A User story is usually a short, simple description of the feature in a format like:
As XYZ Type User, I want to be able to do A, B and C so that We can achieve 1, 2, 3 benefits.
Who Writes these User Stories?
Primarily it is the Product Owner who writes User Stories however there are no specific restrictions as such on who can create a user story. Anyone can write user stories however it is the product owners responsibility to make sure that the backlog of user stories is relevant and in the right priority order.
When are User Stories Written?
Unlike traditional waterfall projects where you start off with the finalized (or at least a baselined) version of the functional specs, Agile doesn’t expect a super well-defined backlog for the entire product feature set. Usually a story writing workshop happens prior to the start of the agile project with user stories being discussed & created for the next few Sprints. During the course of the project, more stories will continue to be created and will get added to the backlog for prioritization.
Of course, some of these initial user stories will be Epic Stories which are quite huge. The team (with the help & guidance of the product owner) will decompose these Epics into smaller stories that can be completed in a single Iteration or Sprint.
Tips to Writing a Good User Story
How to write a good user story. There are a few key tips to help you write a good story.
Tip 1: Keep the User Needs as Top Priority
As the title sounds a User Story is supposed to explain what a user wants and so the needs of the user should be kept as top priority. A user story is supposed to capture a specific product functionality or action that the user would do for ex: As Admin User I should be able to delete unwanted users from the system so that we can restrict access to the System to only “Current” staff.
If you don’t know who the user is or how they would use the product or what action they are going to perform, it would be better if you DON’T create the story because the primary objective is getting defeated.
Tip 2: Keep the Story Simple and Concise
As with any document, keeping it Simple and Concise is a No Brainer. Avoid using confusing or ambiguous terms in the user story. Focus on what is important and leave out the trivial or non-pertinent details.
Let’s look at the Example from Tip 1: As Admin User I should be able to delete unwanted users from the system so that we can restrict access to the System to only “Current” staff.
Is this a good example? If you are unsure, just scroll up to the beginning of the article about what is a User Story and compare this against the template.
Tip 3: Start with Epics
An Epic is a big User Story that doesn’t contain too many details. It often times describes a high level feature and requires a considerable amount of work in order to translate this into working product functionalities.
You may be wondering why should I start with Epics – right?
Starting with Epic stories allows you to chart out the product functionality skeleton without delving too much on details. This is especially helpful for new products because you may not have thought about all of the Nitty-gritties of the product during the initial stages. By setting the skeleton of the feature through the Epic, you are keeping yourself open to the details of the feature which can be altered based on the specific customer needs at that point in time. Typically these Epics get broken down into smaller pieces and then get scheduled during the course of the project.
Lets go back to the example from Tips 1 & 2 – They are very specific user stories but if you rewind the clock a few months back when the original product was being conceptualized, this feature would’ve been under an Epic that talked about Admin User Privileges. This Epic would’ve been reviewed by the team and broken down into smaller Admin User Actions like – Deleting unwanted users, Adding new Users, Editing User Permissions etc.
Now, get the picture?
Tip 4: Collaborate with the Team until the Stories are Refined and Ready
Breaking down an Epic into a smaller user story is not an activity that is supposed to be done by the Product Owner all by himself. It is supposed to be a collaborative activity where the scrum team pitches in with ideas & suggestions until the epic is broken down into multiple smaller, detailed user stories that are:
- Feasible and
All Scrum team members should have a common understanding of the story’s meaning and purpose. Also, the story shouldn’t be too big and should comfortably fit into one Sprint. More importantly there must be an effective way to determine if the story is “Done”.
Tip 5: Add Acceptance Criteria
One of the strongly recommended suggestions while creating user stories is the addition of the Acceptance Criteria. Some agile practitioners refer to this as the Definition of Done but the intent is the same. An acceptance criteria or definition of done basically describes the conditions that have to be fulfilled so that the story can be marked as “Done”. This criteria makes the story testable and also ensures that the story can be demoed or released to the users.
Even the Simplest user story must have at least one Acceptance Criteria. As the complexity level goes up, the number of Acceptance conditions may go up but remember to add them for all your stories.
TRACKING UNFINSIHED USER STORIES
We covered the importance of a well refined Product Backlog, what a User story is, how Story Points are useful in estimation and many other aspects of a Scrum Project. Let’s assume that all of the prerequisites have been taken care of and the team has started work on the first Sprint on a few user stories. It is a very real possibility that a user story that the team started in a sprint were unable to be completed for some reason. How would you handle that situation?
Scrum Explicitly Recommends that each scrum team only pick up so many user stories as they can finish in a Sprint. By finish they mean develop, test, integrate and all those activities that happen before a story can be shipped as a usable feature of the product to the customer. Scrum also recommends that the scrum team and the product owner work together to break-down larger story/feature requirements into smaller pieces that can be individually implemented in a single sprint.
In an ideal world all user stories can be split into small pieces and the scrum team will finish all of its user stories by the end of the Sprint.
The real world paints a very different picture. In any actual scrum project, it is inevitable that you end up in a situation where the team was unable to finish one or more user stories they started during the sprint. So, if this happens, what do you do? That’s what this article is about.
Of course – there is no Right or Wrong way of handling this situation. Scrum doesn’t officially endorse or recommend either of these approaches. As a self-improving team, Scrum expects the team to work together to identify a suitable solution that everyone agrees to handle such instances and deliver a workable product at the end of each sprint. I have tried all of them during different projects and have listed down the Pros and Cons based on personal experience. You are free to choose the approach you wish to take for your scrum team.
Option 1: Move the Entire Story to the Next Sprint
This seems to be the most straightforward approach where, if a story isn’t finished fully, we just move it forward to the next sprint. Simple – right?
As always, the Product Owner is the deciding authority in such a situation. If there are other newer/higher priority stories that are yet to start, the Product Owner may choose to ask the team to hold-off on continuing work on this WIP story and start the others instead. In which case, this story will be paused at hits unfinished state and pending prioritization for one of the future iterations. Alternately, if this story is important enough, the work will continue and the team can finish the story in the next Sprint.
Pros of this Approach:
1. Simple & easy to implement
2. Scrum Team will be ok with this approach as it allows them to continue working on a story without having to worry about finishing it in the current Sprint
3. Follows Scrum guidelines where a story that isn’t completely finished is not counted toward team velocity.
4. Easier for the Scrum Master as he doesn’t need to track story progress on a per task basis to identify how much work was done in a sprint and how much is pending.
Cons of this Approach:
1. Teams Sprint Velocity becomes inaccurate. Let’s say there was a 10 SP story that was started in Sprint 2 and the team couldn’t finish and move it to Sprint 3 and finished it. Now, this 10 SP gets added to the Sprint 3 velocity but that isn’t entirely true. Of the 10 SP only a portion of the work was finished in this sprint. If the team has more than one user story like this that got carried forward the velocity for Sprint 3 may go up significantly while the actual amount of work done by the team was much lower.
2. Unfinished stories may get piled up if other higher priority items get started in the future sprints
3. Status Reporting to Management becomes tricky as the teams productivity for sprints doesn’t include unfinished work. Let’s say in Sprint 2 team finished 90% of a story by spending 18 days of effort and only 2 days’ worth of effort is pending to mark the story as completed. If the story gets moved to Sprint 3, the eventual productivity of the team for Sprint 2 does not count this effort that was already spent on the story.
4. Some Teams may take advantage of this flexibility to carry forward user stories and end up underperforming during sprints thereby impacting overall product quality/features/timelines.
Where this Approach may be most suited:
1. This approach could be suited where every story is an independent workable/usable product feature and can be individually prioritized by the product owner
2. For internal projects where customers are other departments and not paying customers who expect accurate progress/status updates at the end of every sprint
3. For Organizations where the management is willing to allow a certain level of freedom to the scrum team to finish their work in coming iterations without becoming nervous about the reduced velocity in a certain sprint if stories went unfinished.
4. For organizations where the product owner has a well-defined priority order that doesn’t change every iteration thereby allowing team to finish up WIP stories in 1-2 iterations time
Option 2: Split the Story to Carry-forward only the Unfinished part to Next Sprint
After reading the Cons listed above for the “Move the entire story” approach, if you are thinking this isn’t right, this option would be very appealing to you.
The idea here is, we understand how much work corresponding to the story has been completed and then split the user story into two parts. One part corresponds to the work that was completed in the current sprint and the other corresponds to the pending work. The story point size also gets split based on the % complete. If a 10 SP story was 50% complete in a sprint, each split of the story will be 5 SP in size. Straight forward right?
Pros of this Approach:
1. Team Velocity represents the volume of work finished by the team
2. Status reporting becomes easier as all completed work items are represented in the current sprint’s productivity & outputs.
Cons of this Approach:
1. The Intended Purpose or Meaning of the term Velocity becomes Ambiguous. If you go back to the article on Velocity, we had talked about the features the team was able to complete fully in a sprint counting towards Velocity. If a story is partially finished that means the feature isn’t fully usable or shippable to the customer of the product.
2. Completed Stories in the Backlog may not really be Ready for Acceptance. Any user story that is complete technically means the product owner can accept the same and mark the feature as good enough to be shipped to a client. With this story split approach, completed stories represent partial features only and would require the missing features to be implemented in the subsequent iterations before we can mark a feature as a whole as “Ready for Acceptance”
3. Added complexity of tracking tasks in the story on their accurate completion % before stories can be split appropriately. This adds a little bit of overhead for the scrum master as well as some senior members of the scrum team who are also playing roles as team leads.
4. Easier for Status Reporting as every iteration will definitely have a certain amount of work finished by the team and also avoids the spikes & lows in team progress reports. If stories were carried forward sprint 1 could show a very small SP output while sprint 2 could show a high SP output due to carry forward stories.
5. Pushes the team towards trying to mark stories as completed for the sake of boosting velocity. If you go back to my article on velocity, one of the things that scrum teams shouldn’t do is, try to wrap up user stories for the sake of boosting the velocity.
Where this Approach may be Most Suited:
1. This approach could be suited where stories are interdependent on one another and need to be finished collectively for a workable/usable product feature and prioritized collectively by the product owner
2. For external projects where customers are paying customers who expect accurate progress/status updates at the end of every sprint
3. For Organizations where the management prefers to know exactly how much work was completed by the team every week (or Sprint) and gets nervous when stories aren’t marked as completed when a Sprint ends.
4. For organizations where the product owner has a well-defined priority order that doesn’t change every iteration thereby allowing team to split up the stories and finish them across 2-3 iterations time
5. For teams with experienced scrum masters who can use their experience & judgment to guide the team about how to assess completed work as well as split stories appropriately
6. For teams where the team members have experience working in scrum projects and wouldn’t push to mark a story as completed just to boost up the velocity.
Option 3: Rewrite User Story to reduce scope to finish user story in Current Sprint
Though the title sounds simple enough, this option is quite frankly the most complex (of the 3 options of course) and requires a lot of intervention from the product owner towards the latter part of the Sprint.
If a team is unable to finish a user story, we can work with the product owner and the team to cut down on the scope of the story to keep only the bare minimum features the team can finish in the current sprint and then request the product owner to create a fresh user story for prioritization for one of the upcoming iterations.
The complexity arises over the fact that, not all stories can be broken down like this to allow the team to mark a small subset feature as complete. If this was in fact doable, the question that begs to be answered is, why didn’t the team (including the PO) do it during the sprint planning or prior to that?
Anyways, even if teams don’t explicitly try to break down stories/features into smaller chunks, if we try to ask them to rewrite the stories (or further break them down) toward the end so we can mark stories as “Completed” in full, the discipline on creating efficient and concise user stories would happen automatically. If I were the product owner and am being asked by the team to break my story into a bunch of smaller pieces toward the end of the sprint, I may as well do that in the beginning to avoid double effort – right?
Pros of this Approach:
1. Follows the Scrum guidelines of finishing a user story in an iteration
2. Allows the scrum team a certain level of flexibility/freedom because pressure to finish a story in a Sprint may sometimes be counterproductive.
3. Sprint/Team velocity retains its intended meaning and represents the usable features delivered by the team in a sprint
Cons of this Approach:
1. Quite complex and difficult to implement. Not all stories can be split or broken down into smaller pieces. If a feature/story cannot be broken down further, we may need to use the options 1 or 2 we discussed above
2. Some Teams may take advantage of this flexibility to carry forward user stories and end up underperforming during sprints thereby impacting overall product quality/features/timelines.
Where this Approach may be most suited:
1. This approach could be suited where every story comprises of a set of independent workable/usable product feature(s) and can be further broken down by the product owner
2. For internal projects where customers are other departments and not paying customers who expect fully usable/workable features at the end of every sprint
3. For organizations where the product owner is very experience in scrum practices and has the business knowledge to break down every feature/story into multiple smaller pieces.
Some Last Words:
Like I said at the beginning of the article, all these approaches have their own Pros and Cons. Scrum does not mandate us to use either of these approaches. In fact, you are free to add options 4, 5 or even 6 if you think that might help avoid (or handle) instances where stories remain unfinished at the end of a Sprint.
If you have other ideas to handle such situations, do feel free to sound off in the comments section for the benefit of the others.
CAN THE TRADITIONAL FUNCTIONAL SPEC DOCUMENT BE CONVERTED TO USER STORY?
Agile Projects, especially those using Scrum use a Product Backlog which is a prioritized list of product features or functionality. User stories have emerged as the most popular form of product backlog items. If you are someone new to Scrum or if your organization wants to adopt Scrum as the approach for a new project then one of the questions you may have is, can I convert a Traditional Requirement Specs or Functional Specs document into user stories?
I will be using the term FSD throughout this article which is just the short form of Functional Specifications Document (also called as Requirement Specifications or Requirements Document in different organizations).
Reason 1: Different Purpose
An FSD covers the entire set of features the software system is supposed to have and is a binding agreement between the party that commissioned the work (usually a client) and the party that is building the product (a services company). An Agile product backlog is an evolving wish list of features for a product and does not refer to a binding commitment or agreement. When we reach the end of the release there may be some items in the backlog which are yet to be implemented in the product whereas we don’t have that liberty in an FSD. If it is present in the FSD, it has to be implemented – PERIOD.
Reason 2: Size
An FSD does not bother about the size of the feature requirement or schedule or whether the feature can be completed in one Iteration whereas one of the key considerations for a user story is whether it can be finished in One Iteration. If a story cannot be finished in one iteration Scrum recommends that we work with the team & product owner to break it down into smaller pieces. This may not be entirely feasible when we are trying to convert one section of the FSD because the FSD wasn’t built to take these things into consideration (Ref. Point 1 – Purpose)
Reason 3: Dependencies
It may not be practically feasible to implement feature 1.1 of the FSD without also implementing 1.3 and 1.5 (or maybe more) simultaneously. Whereas, every user story is supposed to be a granular piece that can be implemented individually. When we try to schedule user stories we may need to commence on multiple stories in parallel which could result in one or more of them being incomplete at the end of the Iteration. In ideal scrum world the team wouldn’t start off on so many stories if they know they cannot finish but while working on a converted FSD the team may not have that choice.
Reason 4: Priority
There is no specific order in which the contents of the FSD get translated into the software product. The team could go from page 1 until the last page and try to implement those features one by one whereas in an agile environment, any feature the product owner feels as top priority gets implemented first. During every iteration the product owner reviews the backlog and suggests the top priority items for the team to work on.
Reason 5: Change Management
As mentioned in point 1, an FSD is usually a signed off commitment and any modifications to the FSD will require discussions and agreement between the two parties (client and service provider). Formal change management/control processes exist and are invoked when the FSD needs to be modified. Scrum on the other hand is very fluid and the product owner could just create one or more extra user stories to handle the new requirements. Of course, the product owner would need to take out some low priority items to allow the team to work on these new items but still, changes are quite easy to handle in Scrum which is yet another stark difference.
Real Life Trivia: There are many instances where projects with a proper FSD wanted to adopt Scrum and tried to create user stories to replicate the SRS and have the team build the system incrementally. I personally was involved in one such project and trust me it was not an easy one. The 4 reasons I explained above were the main reason the project was so complicated because right from the start. In the end we managed to finish but it was more of an iterative waterfall kind of development rather than pure Scrum because many of the scrum practices had to be ignored. Reason was simple – we were constrained by a signed off FSD which did not allow us any room to negotiate whatsoever with regards to product requirements which is one of the key features of Scrum.
Some Last Words
In many organizations someone in the senior management team decides that the organization will adopt Scrum for their projects and voila people say they are doing Scrum while the reality is very different. An organization before deciding to adopt scrum needs to invest time in training its staff and getting the prerequisites ready before jumping into the scrum ocean. Trying to translate an FSD into a product backlog is one of the more frequent mistakes new adopters of scrum do and that’s why I have tried to explain why it’s not such a great idea in this article.
Do you have any good ideas to translate an FSD into a user story? Sound off in the comments section.