In continuation of previous post…
Overview of User Stories:
Traditionally user stories are hand written on paper cards. Some
times we use colored sticky to write story and place them over a wide board
where each team member can easily view. In
addition to it there are many tools to help write and manage user stories.
Rally and JIRA agile are a few I generally prefer.
It is not required to write all details as stories. Instead the
development team and the customer discuss these details and make a few
annotations on a story card based on the discussions.
Generally a story writing workshop is conducted to write the
stories in the initial phase of starting the project, but this is not a strict
rule. Stories can be written at any time throughout the project. Though the
Product owner is responsible for writing the stories but the whole scrum team
including domain experts do the brainstorming and facilitate Product owner
during the story writing.
Each story is estimated in story
points by the development team. Story points indicate
the size and complexity of the story relative to other stories. These story
points are very useful to determine the velocity of the team. We will discuss
velocity in future. In short we can say that velocity is the number of story
points the team think will be complete per sprint.
Acceptance Tests:
Acceptance testing is the process of verifying that stories were
developed such that each works exactly the way the customer team expected it to
work. The back of a story card holds reminders about how
to test the story. These can be added of removed any time.
These tests capture the expectations of the stake holders that
should be handled by the system.
User Roles:
It is very important to understand that there may be different
users of the product/software. Every user has different perspectives and goals
towards the product. This is the reason that before writing stories different
user roles should be taken into consideration. For example in a B2B or B2C
product there may be internal customers, external customers, admin group etc.
Thus this will have significant impact on user stories. A very fantastic way to
achieve the user role is to have persona. Think for it…and compare with
avatars. I truly look forward to your views on it.
Techniques to write
stories:
There are many techniques and a few are as below.
•
Story-Writing workshops
•
User interviews
•
Questionnaires
•
Observation
Estimating
user stories:
User
stories can be estimated in story points. Planning Poker is one of the
techniques first described by James Grenning (Grenning 2002) and then
popularized by Mike Cohn (Cohn 2006) is my favorite. We will see this technique
in near future. For the fast and furious scrum followers check out your mobile
devices (I used the android play store), you will find many fascinating tools
free of cost for planning pokers.
User stories
are further broken into tasks. Tasks help us to develop in a calculated way.
There is an acronym for creating effective
tasks: SMART’.
S – Specific
M – Measurable
A – Achievable
R – Relevant
T – Time-boxed
Caution: Estimation is the part which is
most concerning to each stakeholder. Let us discuss it further. I expect a few
questions from all reviewers of this post. Till then ‘Have a great day ahead’.
Very good article. Nice read. Regarding the story writing techniques, I think this link (https://www.gov.uk/service-manual/agile/writing-user-stories.html) explains a very good technique by dividing the user story in 3 components namely actor, narrative and goal. Also, I believe including a full user journey in a story is not a bad idea at all.
ReplyDeleteLet me describe the question now. Should there be any predefined time frame for story writing (Please mind my knowledge (or the lack of it) about agile here)? In other words, should there be an unsaid rule of ratio of amount of time spent in story writing and amount of time spent in the whole sprint (let's call it ratio Z) being near certain value? Let me exemplify my question to make it more clear.
Let's assume that you have developed and are managing the online banking solution for some xyz bank. Now, the product owner comes up with idea of changing the interest calculation algorithm. They want to change it in such a way that it calculates interest daily rather than monthly/quarterly. Now, being a preacher of your application, you know that it is not a big change technically, as you just need to change the centralized interest calculation algorithm and its frequency of execution. However, the areas it touches are plenty. So, we are in a situation where the implementation can take 5 hours and story writing may take 3 days (as we have to include all the details in the story to avoid the possible maintenance repercussions). So, should we inform the product owner that the change can take 4 days (or more as I haven't considered testing/other efforts). If not, should we cut the details to be included in a story?
All in all, should there be any trade off between the amount of details to be included in the story and the time to be spent for it (i.e. amount of details and infamous ratio Z as described above)?
Sorry for the long post.
Hey dear, thanks for going through this article and of course for the question. I am providing a few details of user stories. Hope this will answer your question.
ReplyDeleteMost of the user stories are written in story writing workshops but stories can be written at any time throughout the project because the requirements change over a period of time when more knowledge is gained. That is why new user stories may be created or old stories may be modified/ voided through out the project. User stories are written by Product owner with the help of ScrumMaster, development team, stake holders and domain experts.
There is no defined timebox for story writing workshop. Generally it takes a few hours to few days. The story writing is done before the sprint starts so there shouldn't be any ratio of story writing with the sprint. Goal alterations are generally not permitted between sprints unless critical. However if the story has to be written and developed within an ongoing sprint and developing it will impact the sprint then a few stories of the sprint may be dropped from that sprint by the product owner after consulting the scrum team.
Stories should be very short and should not include extensive details. Stories are the placeholder for more detailed future discussions that will take place among the stakeholders, product owner and development team. The details are communicated in these discussions. User story is simply a reminder to have that discussion which is not a one-time event, but rather an ongoing process till the story is not developed as per the requirement. Note that it is not necessary to note down the details as a document which generally happens in waterfall model.
Hope this helps. Please let me know if any point needs more clarity. ( I know certainly there will be :-) ) I will be happy to reply.
I agree with your point of having full user journey as it envisions a user perspective and helps to build a right product. But it should not be in a user story. This comes under user role modeling. I will provide more details on user role modeling in future post.
Thanks for the crystal clear explanation. The line "The story writing is done before the sprint starts so there shouldn't be any ratio of story writing with the sprint" answers my question profoundly. However, I have one more question, hope you won't mind it :)
ReplyDeleteAs per the explanation in the blog as well as comment, communication with the stake holders, PO and development team is very essential for the sprint to complete successfully. However, there are some cases were such communications are not possible e.g.
1. If you are developing a complex module, you will have some questions, answers to which will lead to another set of questions and so on. It may result in endless discussions.
2. If the work is outsourced, you may not be able to resolve the questions timely as communication may not be possible due to timezone differences(or other factors). It may not be feasible for developers to communicate with sake holders every time a question arises. Delay in which may affect the timelines.
3. You are developing a part of complex system and different parts are being developed by different organizations.
In all these cases, communication may not be feasible every time. So, which approach we should go for?
Hi Darshan, I understood your question as this really happens with agile teams during development and specially the development team faces the absence of Product owner quite a time which impacts negatively.
DeleteSuccess of any complex project depends on continuous communication and feedback from the Product owner/stake holders. Not only the projects following agile practices, more and more project development practices/methodologies are focusing intensively on stake holders and communication with them. PMBOK 5 (Project Management Body of Knowledge 5) has also included ‘Stake holders Management’ as its 10th Knowledge area.
Now the point is about the yardstick of a successful project/sprint. This varies with the people and the organizations. However success for the projects following agile practices is often identified by the satisfaction of customers/stakeholders. And yes, I agree with your point that lot of communication needs time and may impact timelines but as I indicated that even if it takes more time during the development and leads to produce right product/module, it will be a successful product instead of delivering product in time with improper implementation of any functionality due to lack of communication that led to not understanding the exact requirement.
By saying the above point, I am not advocating of delaying the sprints/modules. I am just making clear the definition of success through continuous communication of agile team with stake holders. Most of the time, the Product owner as a representative of stake holders, interacts continuously with the development team to answer the questions raised about the functionality being developed. If due to busy schedule/different time zones the Product owner is not able to communicate with scrum team, there is a provision of Proxy Product owner. Being a domain expert and an authorized person, proxy Product owner replies the query of agile/scrum team. For vast projects with lots of features there is one Chief Product owner who has other ‘Feature Product owners’ working for different features/parts.
I also prefer working product owners working in shift in order to make a successful product. After all we will leave no stone unturned for the success of the product. Isn’t it? :-)
My reply may have left a few questions unanswered or may have created a few more queries. Please do asking questions on such important aspects.
Just to add one more point that the Proxy Product owners may work with the development team as per their work timing or may work in such a way that there may have at least 4 to 5 overlapping hours among scrum team and* Product owner.
Delete*(As we are talking about Product owner's involvement in scrum team so I referred him separately otherwise Product owner is a part of scrum team itself.)
Hi D n D, Good to see you both on blogspot!!! As an outsider, this will be the first question anyone can jump in with when we are talking about Agile and Scrum. Working with SDLC over the years with waterfall cycles, we are used to with these kind of questions.
ReplyDeleteFor the first question, i would say when you have anything that is affecting your deliverables or timeline, you can put them upfront as risk or impediments. Something that requires X, requires X and can not be done in Y (X>Y). And that is the beauty. And when you say you want to create complex module, i would say complex modules are broken upto the level where you are at some level where complexity is not that complex and that too in small pieces, your X^3 complex module is broken into X, X and X, and that is where the Agile plays a role.
Communication between Devs, PO and Stakeholders is most important in Agile. However, work being outsourced and team being at different geological locations, does not give that much Agile and make us somewhat fragile. Having said that, it does not stop us doing anything, delay in communication or responses from PO or Stakeholders can be one of the impediments you can highlight and that is quite important as far as this process is concern. Ability to highlight Problems/Risks/Impediments in meetings will help you come out of it and help you define your Team Velocity.