Welcome to the Simplilearn Community

Want to join the rest of our members? Sign up right away!

Sign Up

Agile scrum master

DeshDeep Singh

Well-Known Member
Simplilearn Support
Alumni
Disadvantages of using Chrome Book:

1. No third Party software can be installed or run on it. E.g. WebEx, Team Viewer, VMWare, CAD Tool etc.

2. Microsoft office has no relative version for Chrome Book.

3. Everything in Cloud storage, as Google offers 2 years Google drive 100 GB access.

4. Its actual functionality comes out when connected to internet.

5. Cannot connect computer to Printer or other devices.

All the above mentioned points are our day to day activity when it comes to use a PC or a Laptop, all of them are ignored in Chrome Book.

Now, after reading these 5 points, it becomes really easy to make choice before buying a laptop.

I prefer Mac OS or Windows OS because it gives us access on any third party software which becomes easy to install and have hands-on.
 

riteshindupur(3638209)

New Member
Alumni
Hello Everyone....i am adding some challenges that I have faced during my experience in Agile.

Challenge 1 : Self Organizing Team. Agile emphasis on self organization where the team members can execute without continious direction. Agile team members are considered to be independent. It is based on working relationships, trust and common understanding.

Reality : In reality though, Large and complex projects do not very easly bring out well organized teams.

Request all to share your thoughts.

Happy Learning !.
 

AmerNatarajan

Well-Known Member
Simplilearn Support
Alumni
Hi All,

I will be sending a mail by EOD today defining the exam process clearly and also the details required to book an exam/exam voucher
 

Rakesh Deshpande

Moderator
Simplilearn Support
Hello There,

Here is the document for your reference.
 

Attachments

  • Backlog, and other slides (1).pdf
    319.6 KB · Views: 21

Sushant Tarway

Active Member
Alumni
Hi Karam,

This is in regards to follow AGILE in my project. What are the first things I should start looking at when I am on the floor today with regards to start getting into AGILE. Are there a list of habits that one needs to follow in his/her projects when starting thinking in AGILE way!
 

Rakesh Deshpande

Moderator
Simplilearn Support
Hello Everyone,

There is an important announcement, Since there is an issue with respect to the recordings of the session, We have escalated it to the concerned team and the team is already working on the resolution. We request your co operation for next 2 - 3 working days since all the links are re-synced and provide you error free links. You might not see the " Download Recordings " on your batch. Do not worry, it will be visible once the issue is resolved. Thank you in advance.

You can always chat or get on a call with us for an instant response. We're always around to help you achieve your career goals!
 

Karam Labban

Member
Trainer
Excellent question Sushant.

Here is a list of habits and pointers that I hope you find several you can start using now:


  1. Understand and guard the Agile principles.
  2. First try an Agile method (i.e. Scrum, Kanban. etc.) in its pure form before considering modifications. Avoid partial adoption initially.
  3. Don’t be afraid to fail, even during user demos, as long as you learn and improve.
  4. Continue to find ways for improvement
  5. Join Agile user groups to share and learn.
  6. Always evangelize Agile internally and to clients and vendors.
  7. Educated all levels of the organization on Agile and the method you are using.
  8. For PMOs, don’t start all critical projects at the same time. 12 vs AT A TIME
  9. Just like user stories in a backlog, projects also need to be prioritized into an Enterprise backlog
  10. Reduce multitasking to a minimum. Multi-tasking negatively impact quality, team spirit, false feeling of be productive. Make sure Sprint rules and WIP limits in case of Kanban are adhered to.
  11. PMOs and leadership should not use command and control and embrace servant leadership.
  12. PMO and leadership should start thinking in the way of stable cross functional teams and not availability of resources individually.
  13. Focus on what and not on who during retrospectives or during Kaizen meetings.
  14. Focus on excellence more than on maintaining positive metrics.
  15. Embrace that plans change.
  16. Focus on delivering products and services vs. ‘projects’ Not all stories are done at the end.
  17. Don’t run every decision by the leadership. The team should be empowered and trusted to make many of the decisions.
  18. Don’t seek certainty. Don’t lured by that concept
  19. Don’t over plan.
  20. Don’t over commit to please anyone.
  21. Don’t avoid conflict when needed.
  22. Don’t waver away from the key Agile values (Communication, Transparency, Honesty, incremental effort, and incremental learning and feedback)


Let us know what you think.

Thanks,

Karam





Hi Karam,

This is in regards to follow AGILE in my project. What are the first things I should start looking at when I am on the floor today with regards to start getting into AGILE. Are there a list of habits that one needs to follow in his/her projects when starting thinking in AGILE way!
 
Last edited:

Rakesh Deshpande

Moderator
Simplilearn Support

Attachments

  • Screen Shot 2017-01-22 at 7.58.23 AM.png
    Screen Shot 2017-01-22 at 7.58.23 AM.png
    235.4 KB · Views: 12
  • The Chcicken and the Pig - Agile Scrum.jpg
    The Chcicken and the Pig - Agile Scrum.jpg
    45.9 KB · Views: 11

Karam Labban

Member
Trainer
Hello Class,

Here are some of the books you will need for the Exin exam and as good knowledge on Scrum, links, and pics I shared I with you earlier today during session#3:

Succeeding with Agile: Software Development Using Scrum by Mike Cohn.
https://books.google.com/books?id=I...ce=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

Agile Estimating and Planning by Mike Cohn.
https://books.google.com/books?id=B...ce=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
https://books.google.com/books?id=3...ce=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

Fragile Agile: Coaching a Tired Team by Anna Obukhova on Jan 24, 2017
https://www.infoq.com/presentations/agile-tired-team#downloadPdf

I will share the Excel sheet and the powerpoint slides later.

Thanks,

Karam
 

Attachments

  • 8591351239_24bcb987df_c.jpg
    8591351239_24bcb987df_c.jpg
    442.4 KB · Views: 9
  • Business Value Points Cheatsheet.pdf
    235.5 KB · Views: 7

Karam Labban

Member
Trainer
for some reason this website didn't allow me to upload an Excel file so I thought I at least share a screen shot of it. I hope you still find it helpful. Please find it attached. Thanks
 

Attachments

  • Cost of Delay.png
    Cost of Delay.png
    488.3 KB · Views: 10

Karam Labban

Member
Trainer
Hello class,

Here are the files (attached) and links I shared with you during the live sessions today:

Collaboration rooms for distributed teams:
https://www.sococo.com/

The site for the estimation game we played:
https://planningpoker.com

Book: Agile Software Development: The Cooperative Game by Alistair Cockburn
https://alistair.cockburn.us/get/1885

The scaled Agile frameworks:

https://www.scaledagileframework.com/

https://less.works/

http://www.enterprisescrum.com/?gcl...zZR_kBVNjumUbNu4f-LiP9rgj3UKiBXP7IaApnu8P8HAQ

https://www.scrum.org/Portals/0/Documents/Collateral/NexusPoster17x11.pdf

https://www.scrum.org/Resources/The-Nexus-Guide

I will post my extra slides later this week.

Thanks,

Karam
 

Attachments

  • Agile Planning Poker Cards.pdf
    435.8 KB · Views: 7
  • Agile PMOs Dos and Donts.jpg
    Agile PMOs Dos and Donts.jpg
    80.1 KB · Views: 12
  • AgilePMOTransformation.pdf
    182.2 KB · Views: 6
  • Estimating_Feature_Points.pdf
    169.3 KB · Views: 10
  • Story Points Estimation.pdf
    89.6 KB · Views: 9

Ferenc Meszaros

Member
Alumni
for some reason this website didn't allow me to upload an Excel file so I thought I at least share a screen shot of it. I hope you still find it helpful. Please find it attached. Thanks

Hi Karam,

Is it possible to send the spreadsheet to Rakesh and he can share it with the participants?

Many thanks,
Frank
 

Rakesh Deshpande

Moderator
Simplilearn Support
Note : Important Announcement!!

Hello ,

As you are aware that We have added project(s) as a part of study curriculum where you will work ( Mandatory ) on the JIRA Tool to learn and gain the hands-on experience. Here's what you have to do :
  1. Create an Account in JIRA Tool ( For further info : Please watch the last recordings of the batch you attended for ).
  2. Create A project in the Tool and Create a product Backlog! ( Note : The duration must be minimum 2 weeks for the Entire project)
  3. You will get the information about the projects under Downloads of Learning Tools in your E-Learning / Learning Management System.
  4. Spend atleast an hour on the project created and work upon the backlogs etc from the start of the sprint till the release of the project.
  5. Here are the mandatory screenshots to be shared with us to award you the Project Experience Certificate powered by JIRA.
    • Screenshot of the Burn down chart/Screenshot of the initial Product Backlog.
    • Screenshot of the invited 4 colleagues (Minimum)who act as a part of the project. ( You can add rakesh.deshpande@simplilearn.com counting as 1 out of 4 ).
    • Screenshot of the initial scoreboard of the project ( which consists To-Do list, Work -in- Progress , Done).
    • Screenshot of the final Scoreboard of the project ( Which has all the issues mentioned under Done ).
  6. You will receive the certificate on approval of the project in 3 business days.
 

Ferenc Meszaros

Member
Alumni
Hi Karam,

During one of the sessions you showed us a sample of the definition of done spreadsheet. Would it be possible to share that as well?

Many thanks,
Frank
 

Karam Labban

Member
Trainer
Hello Frank,

I believe it was a list of suggested items like:

Code for the story passes all:
Automated unit
Acceptance
Functional tests
All tests for the story are automated
Code passes all static analysis criteria
Story passes all usability or user acceptance tests

All end-user documentation complete for the story
All field-support documentation complete for the story
All installation guidelines and installation scripts are complete
Code complete and accepted by Business Partner
Demo ready (presentation slides, hands-on testing steps… etc

Basically, all steps that are needed for the PO (representing the business) and the team to consider the story is complete and accepted. Closed.

Thanks.
 

Ferenc Meszaros

Member
Alumni
Hello Frank,

I believe it was a list of suggested items like:

Code for the story passes all:
Automated unit
Acceptance
Functional tests
All tests for the story are automated
Code passes all static analysis criteria
Story passes all usability or user acceptance tests

All end-user documentation complete for the story
All field-support documentation complete for the story
All installation guidelines and installation scripts are complete
Code complete and accepted by Business Partner
Demo ready (presentation slides, hands-on testing steps… etc

Basically, all steps that are needed for the PO (representing the business) and the team to consider the story is complete and accepted. Closed.

Thanks.


Great, thank you very much for that.
 

Karam Labban

Member
Trainer
Greetings,

It was real nice having you all in the sessions these past weekends. Thank you again for your time, interaction, and feedback.

Here are the the two online resources I shared with you. I also attached the supplemental slides I used for the refresher on epics/stories/tasks. I uploaded them as JPGs because in a PowerPoint file, the file size crossed the upload size limit!

The Annual report showing Jira as top tool made for Scrum/Agile. The report has some other eye opening and helpful findings:
https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf

Developer picks: 7 hot tools for agile development
https://www.infoworld.com/article/2...7-hot-tools-for-agile-development.html#slide2

Thanks.
 

Attachments

  • Example Requirement Levels.jpg
    Example Requirement Levels.jpg
    59.4 KB · Views: 9
  • Stories Can be Complex.jpg
    Stories Can be Complex.jpg
    386.5 KB · Views: 8
  • Stories Can be Compounded.jpg
    Stories Can be Compounded.jpg
    369.6 KB · Views: 7
  • The Cone of Uncertainty.jpg
    The Cone of Uncertainty.jpg
    318.5 KB · Views: 9
  • The Lifecycle of User Stories.jpg
    The Lifecycle of User Stories.jpg
    240.6 KB · Views: 7
  • The Levels of Requirements.jpg
    The Levels of Requirements.jpg
    313 KB · Views: 7

Sushant Tarway

Active Member
Alumni
Definition of Done (DoD) to ensure best scrum deliverables
I was reading about Definition of Done , thought of sahring to the community
(Referene: ww.yodiz.com/blog/using-definition-of-done-dod-to-ensure-best-scrum-deliverables/)

Definition of done (DoD) is the checklist to ensure product quality of your deliverables. It avoids awkward situation for team during the sprint demo.
Definition of done is like an IKEA furniture’s manual, which needs to be followed step-by-step to have a desired end product. Failing to do so, will end up waisting time with unexpected results.



Scrum Definition of Done checklist






Why it is important to follow?
Most perfect and well planned sprint can be ended up like this, if Definition of Done is not to be considered seriously.




Who needs to enforce DoD?
Definition of done need to be enforced by scrum master during sprint, Scrum Master to make sure that the team put the focus in the right activities and in the end produce the product which is “shippable “.
Even though concept of “Done” is understood as “almost done” by some scrum teams, but almost done is not done at all. The actual definition of done if exist at all, only exist in the mind of “Product Owner” and “Scrum Master”, this is a basic principles where most of scrum team tends to fail. Product owner should carefully craft the Definition of Done, this is a live piece of checklist which need to be updated regularly, Product Owner need to make sure that scrum team fully understand the criteria on which the userstories would be judge and accepted during the sprint demo.

Where it all begins
As “almost done” is not done at all, poor quality of software or unDone User stories, in the end of sprint is not something which scrum team should be blamed of.
Assuming that User stories are defined well by Product Owner, but recipe to combine the different element in scrum are not defined .Well, assuming that there are no emphasis on testing, coding standard, integration testing, UX review, documentation, unit testing etc in scrum, so team will not take under consideration those very important task, when estimating their work, which resulting in poor sprint deliverables.
Definition of done is the recipe for improving quality, all functional requirement is defined in User stories, but the things which bring quality and disciplines is come from DoD.
This is the major activity which judge the quality of your SW and all your reporting for Scrum demo should be based upon


Definition of Done Checklist
The main goal of Product Owner (PO) is to define and provide the clear checklist to which all the User stories are judge against. So when developer think of estimating task (s)he should estimate considering those activities in DoD checklist, PO need to make it very clear that end of sprint what ever line of code is written will be shippable as a real application to real user.

Main activities in definition of done
Coding
  • Well written code
  • Peer code review
  • Coding standards
  • Unit testing
SW version control
  • Build Environment
  • Continuous build environment installed
  • Continuos integration and testing
Testing
  • Smoke testing
  • Integration testing
  • Release testing
  • Regression testing
  • Documentation
  • Release notes
  • Design documents
Bugs
  • Ideally no critical, major or minor issues.
  • All known should be reported in issue management tool.

 

Sushant Tarway

Active Member
Alumni
What is a user story
In Agile methodology ‘User Story’ is a unit of work that should be completed in one sprint. Smaller than that it’s a task, more than week(s) of work is Epic or Theme.

The agile recommendation is to break down a set of user stories into smaller ones, containable into a single sprint duration, or ideally, a user story shouldn’t last more than a week.

One thing to keep in mind is that some of the agile “best practices” are to avoid having child stories, it is not a good recommendation to have user story in nested hierarchy, as that is also hard to model with stickies on a whiteboard.

There are some tools providing support for nested hierarchy of user stories, but you should avoid it. Keep the stories as a flat list, all at the same level.

How to write a user story
As a ____, I want ___, so that ____


User Stories doesn’t need to be this format. The user story format is not a requirement of Scrum. but it helps to force the story writer to articulate those important three questions.

  • Who are we building it for, who the user is? — As a <type of user>
  • What are we building, what is the intention? — I want <some goal or objective >
  • Why are we building it, what value it bring for the user.? — So that <benefit, value>
User story Template
Having a template for a user story, provides a good guideline. It helps avoid common problems and pitfalls. With a template, you get to see what user role the story is for, what they want to be able to do, and why. Then you as PO and the developer[Team] get to figure out how to accomplish that. Engineers and POs do not use the same language/not understanding each other. This template force some a common principle and help to understand what should be written to be understood well by both parties

User story template describes both the requirement and the value to the stakeholder. There is no specific format for defining a user story in agile, agile doesn’t force any kind of template for a user story.

The concept of writing a user story is to start a conversation around the story, and the mutual understanding that we try to build, the value we want to offer to a user and how the user will utilize it.

Do not write a user story for the sake of writing it. People tend to think that they’re done with writing a user story when they managed to fill in the blanks in the template, but someti it just doesn’t fit.

This is a very bad example of user story and agile world is full of these user stories

As a user, I am able to able to provide best support service to my customer.


Practical example of user story Template
Screenshot bellow is the real story from our sprint, it is shown as is without any modification, idea is to show how we are using agile and what is our template of user story look like.

User story bellow is a result of feedback we receive from a customer, 80% of the sprint content is based on direct feedback from customers.

user-story-template-example.jpg

Our prioritization is based on the value proposition for the requested feature or feedback.

How we receive user stories
We are in direct contact with customers via phone call, skype, twitter, email, uservoice and real-time chat[intercom.io] . We instantly forward the email to our Yodiz project. In Yodiz you can create user story, issue and epic via email, please check the link here.

Why you should write a user story
As a Product Owner (PO) when you receive a user story from any source you should be asking yourself following questions

1) Why are we doing this, what is the business or technological gain?

2) What is it for, who will be user actually using it, remember the 80/20 rules ?. If you are spending too much effort on providing the feature which is either not requested by many users, or doesn’t add much value.

3) What value does it drive, what is monetary, user, or UX gain of that user story?

4) what’s your estimates on time to implement?

5) what are the acceptance criteria or CoS (condition of satisfactions)?

6) what testing will be needed?

7) What support can you give?

8) what is your marching order, does the story fit well in the marching order?

Product owner and the team should decide on what they feel is the most appropriate way to describe the work that needs to be done. As team know how part and PO knows the what part

What user story is really for
User Story is only meant to describe a feature, but not describe how to implement it, meaning leaving out the technical aspect, it should describe the behavior or flow from user’s perspective.

A user story is basically a use case. What do your users need the software to actually do? A story should be a unit of work that a team commits to in a sprint. Whether or not that unit requires subtasks should be up to the team.

Story points for user story estimation
Sizing of the story point of early adaptors of the scrum, as sometimes a story will be small enough if we do too much slicing vertically, other time it get way too bigger, as we keep on stuffing the feature in one single user story.

Reason of having story point
This is why we have story points. The points are a fuzzy measurement of how big or small a story is, and should be estimated by the engineer(s) who are implementing it or someone with superior knowledge about the work. In organization/team there should have a standard scale for story points measure, so you can compare multiple stories and say and have some reference like you are able to say that those seem like a similar amount of work like that user story.

More often used is Fibonacci numbers, which is fairly standard. The points don’t really “mean” anything, though, they don’t equate to the amount of time spent or effort for implementation, its simple way of calculating a relative complexity or measuring to get to point A to point B.

Definition of Done (DoD), Acceptance Criteria or Condition of Satisfactions (CoS)
As you fine-tune your estimation, the team should be able to reliably pick up as many stories as they can handle. If your process is working well, that number will probably slowly increase over time, but it take 5–10 sprints to master this technique.

You must define your Definition of Done (DoD) for stories, acceptance criteria or condition of satisfaction (CoS ) . This helps set expectations within the team as to when a team should consider something done. It also help to write detail level of test cases other advance of writing CoS, DoD or acceptance criteria is, you force yourself to think like an end user. What comes out of this approach is much different than writing user story as a PO

Characteristics of a User Story
  • A story should be complete and big enough to provide a user with some value. The user story should be user-centric, normally people write user story which is too much centric around component or system aspect, when writing a user story, we should focus on what the user is doing or getting out of the story.
  • The goal is that when the user story is done, the user can do something of value to them.
  • Group user stories which offer a feature in the same domain, or its good to group a certain feature or use case into a single Epic or even multiple Epics. Ideally you’ll break up your features in a way that you can launch into production parts of the feature independently from the whole, but its not always possible.
Grouping user stories
Epic is simply a story that is too big to fit into a single sprint or too complex to estimate. To cut off or slice horizontally a bigger story/epic, is highly dependent on the team itself. Not all stories necessarily need to fit under an epic

Once something you find which is above the threshold of a user story, it should be broken down into more manageable chunks.

Epics are like chapters in books, themes are like a collection of books on the same topics, while the project is a library which contain all those books.

User story grooming session
It is highly recommended to go through the user stories with a group of stakeholder and some of the team members. It help to describe what’s needed in order for the item to be ready for development and to which priority.

Sprints are meant to allow you to deliver finished parts of the end product. As simple as they may seem, it requires a proper planning, it require to have perfect input and need to specify acceptance criteria.

How to run grooming session for the user stories.

  1. Send a recursive invitation for grooming session. Depending on your sprint duration, if you are having two long sprints then it’s ideal to have grooming session every month or every two week, it should while sprint is in the middle.
  2. Prioritize the backlog as good as you can, ask the participants to through the userstroies before coming to meeting, so there can be a detail level of discussion
  3. You can invite people from technical team, not all members need to be there, but some senior memebers, architect or someone with good knowldlege about the user story in quesiton should be invited, then there should be people from business, sales or stakeholders, the internal customer they people who requested those user stories.
  4. It is important to run the meeting as timebox for 1 hours, more then that its waste of time, you can have biweekly shorter meeting, its not a good idea to spend 3 hours for grooming session, as its not very productive.
  5. Go through the user stories in detail, try to finalize the open questions, perfect your mokups and describe and verify your user flow.
  6. If budget is available order the lunch or coffea/cake
  7. Take meeting notes and write clear action points like what to be updated by who, etc
INVEST
Last but not least, we can not close the discussion about user story without mentioning the INVEST

Slice horizontally the user stories by using INVEST acronym

  • Independent — Can the story stand alone by itself ?
  • Negotiable — Can this story be changed or removed without impact to everything else?
  • Valuable — Does this story have value to the end user?
  • Estimable — Can you estimate the size of the story?
  • Small —Is it small enough?
  • Testable — Can this story be tested and verified?
Conclusion
How you write a user story, what is the most difficult thing to overcome when writing a user story.
(Reference : https://www.yodiz.com/blog/writing-user-stories-examples-and-templates-in-agile-methodologies/)
 

Sushant Tarway

Active Member
Alumni
User Story Characteristics in agile scrum methodology


User Story Characteristics In agile Scrum Methodology
User story is a description of objective, which helps a person to achieve a feature. So that he able to utilize that feature when using software application.

User story is a part of Agile development process. Every process has some characteristics which makes it clear and concise. User story is a first process is Agile development process. A good user story can convey a good understanding to programmer about requirement.
User story is a description of the user valuable features , good user story should include the roles, functions and business value of three elements.

As a (Role)
I Want (What)
So That (Why, Benefit)

User stories are most popular agile technique. It helps to capture the product functionality. User stories make work easy. Definition of an effective user stories can be hard. These given tips will help you to create an effective user stories.

Microsoft Press defines Acceptance Criteria as:
“Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.”

Google defines Acceptance Criteria as:
“Pre-established standards or requirements a product or project must meet.”

User Story Characteristics
Here is a short, but informative list of user story characteristics.

  • A good user story should be complete enough to provide a user with some value.
  • The good user story should be user-centric, normally people write user story too much centric around components or system aspects.
  • When writing a user story, focus on what the user is doing or getting out of the story.
  • The goal is that, when the user story is done, the user story has some value for users.
  • Group the user stories which offers a feature in same domain, or its good to grouping a certain feature or use case into a single or multiple Epics.
  • A good user story is written in one to three lines.
  • Some user stories have attached files to elaborate the user story more clearly.
  • Good user story is well-defined, well-detailed and comprehensive.
  • A good user story is helpful to capture a specific functionality.
  • Involvement of development team in the user story is important.
  • A good user story is simple and concise.
  • Good user story should always be in active voice. Do not use ambiguous and confusing terms.
  • Good user story only focus on important part and leave out the rest.
  • Start with an epic, when writing a user story about new product and feature because it allow to capture the rough idea about product with less detail.
  • User Stories are used to communicate information, so make them visible and accessible.
  • Good user stories are complemented with other techniques like, story maps, sketches, mockups, storyboards and workflow diagrams etc.
  • Try to avoid dependencies between stories, dependencies between stories will have priority and planning issues.
  • The story should be negotiable. User story should be changed or removed without impact to everything else.
  • The best valuable user story is that one, which is written by user or customer. Give value to each user story which writes by user of customer.
  • Developers should be able to predict (at least rough guess). They predict about time scale of stories , and to achieve the desired encoding.
  • The story of scale is depend on team size, capacity development group , as well as technical realization.
  • Good user story is a story which is easily testable. We cannot develop, what we cannot test. A non-testable user story is : “software should be easy and pleasant to use”.
There are two helping methods for writing user stories:

  • Invest (This technique is helpful for user story)
  • Smart (SMART is for the tasks of a user story)
Bill Wake’s user story Characteristics:
To build a good user story , we focus on six characteristics. A good story should have characteristics. Bill Wake described six characteristics of a good user story. We entitle his formula as “Invest”.

Invest
  • I) Independent
  • N) Negotiable
  • V) Valuable
  • E) Estimable
  • S) Small
  • T) Testable
Independent
We must try to avoid the interdependence between the story. When the story prioritize, plan to do or when to use the story, the story of the interdependence between the estimated workload will cause more difficult. Usually we can reduce the dependence of two ways:

  • Interdependent story combined into a large, separate stories
  • With a different way to split the story
Negotiable
Story card is a brief description of the function, the details of the discussion will result in customers and development teams in. The story is a reminder of the role of card developers and customers to engage in dialogue on demand, it is not a skill specific needs. A user story is a cassette with too many details, effectively limiting and user communication.

Valuable
User Stories should clearly reflect the values of the user or customers, the best approach is to allow customers to write the story. Once a client realize that this user story is not in contract and can be negotiated, they will be happy to write the story.

Estimatable:
Development team needs to estimate a user story in order to determine priorities, workload scheduling. But let developers is difficult to estimate story Problems from:

  • Developer lack of domain knowledge
  • Developers lack of technical knowledge
Story too . . . .

Small
A good story on the amount of work to be as small as possible , preferably not more than 10 people over the workload / day, at least make sure that in one iteration or Sprint that can be completed. User Stories larger scheme of arrangement at risk , effort estimation and other aspects will be.

Testable
The story must be testable . Successfully passed the test developers can prove that correctly implements the story. If a user is not able to test the story , then you will not know when it can be done . An example of a non- test user stories : The user must find the software very easy to use.

Related: Agile User Stories and Groomed Product Backlog

Smart:
SMART is not for user stories but for the tasks of a user story.

  • S) Specific
  • M) Measurable
  • A) Achievable
  • R) Relevant
  • T) Relevant
Specific
A task needs to be specific enough so that everyone can understand it. It helps to keep other tasks from overlapping, and also helps people to understand either the tasks add up to the full story or not.

Measurable
The key of measure is, “can we mark it as done?” Team needs to agree on what that means, but it should also include:

  • “what it is intended to”
  • “tests are included,”
  • “the code has been refactored.”
Achievable
The task owner must be able to achieve task. In XP methodology, teams have a rule, in which anybody can ask for help whenever they need; this is certainly includes ensuring that task owners are up to the job.

Relevant
Every task must be relevant and story contributing. User stories are broken into tasks for the developers benefit, but customer should still be able to expect that each task can be justified and explained.

Time-Boxed
A task should be limited to a specific duration. This doesn’t need to be a formal estimate in hours or days, but there must be an expectation so people know, when they should seek help. If a task is harder than expectation, then the team needs to split the task, change players, or do something to help the task (and story) to get done.

(Reference : https://www.yodiz.com/blog/user-story-characteristics-in-agile-scrum-methodology/#post/0)
 

Sushant Tarway

Active Member
Alumni
Agile vs Waterfall Differences in Software Development Methodologies
Agile_vs_Waterfall_Differences_in_Software_Development_Methodologies.jpg


Agile vs Waterfall Software Development Methodologies Differences
Every development methodology has it’s pros and cons. Selection of best development methodology is based on work status and team standard. Most commonly used development methodologies are Waterfall and Agile. Both methodologies have their advantages and disadvantages.

Waterfall development is an uninterrupted series of events from conception to production. While
Agile is a flexible, team-basic, iterative approach to lean production. Both processes can be used for project development, just in different ways.

What are Agile and Waterfall methodologies
Let’s start from the basics of those methodologies, we describe bellow the pros and cons of Agile and Waterfall.

What is Waterfall?
Waterfall is a sequential (step by step) process methodology where project is broken into stages which are completed in a sequence. You must need to complete first phase before proceeding to another one.
There are eight step in every waterfall development process. In waterfall methodology developer goes further step by step. These eight steps are listed here :

  • Conception.
  • Initiation.
  • Design.
  • Construction.
  • Implementation.
  • maintenance.
What is Agile?
In Agile, development is divided into small iterations which are called sprints. This is a better development methodology due to its continuous planning, testing, integration, risk evaluation and control on the progress of the project and thereupon reduces the chances of project failure.

This methodology is one step forward than waterfall. Agile methodology was created after facing the lot of disadvantages of waterfall in many procedures. Rather than working in sequential design like waterfall, agile work in incremental (Regular series) approach.

In Agile, a project is converted into small parts known as sprints. Each sprint can be completed using waterfall steps. Like, Conception, Initiation, Analysis, Design, Construction, Testing, Implementation and finally maintenance.
This is the point where we can say that Agile is just like micro waterfall, as in each sprint we go through steps which we go through during a project in waterfall.

Advantages and disadvantages of Agile vs Waterfall
Advantages of Waterfall
Waterfall methodology is like a complex record keeping methodology. These records help a lot in future programs.

  • Waterfall is a sequential and well structured process.
  • It is a simple and easy development model to understand and use.
  • It is not changeable at any step and is easy to manage because of its consistency.
  • Requirements are very clear and easy to apprehend even before development.
  • Each divided part is completed in specified time period.
  • Implementation is easy because of linear pattern.
  • Less amount of resources are required to use waterfall model.
  • Development quality is better because of proper documentation.
  • Suitable for processes where backlog changing is not required.
  • This process needs clearly defined requirements.
  • In Waterfall clients know about the size, cost and timeline of projects.
  • Clients have a clear idea about program output.
  • Due to strong documentation any kind of employee turnover will not affect the project.
  • This methodology is very helpful to manage dependencies.
Advantages of Agile
Agile means “moving quickly indicating the dynamic approach of Agile.

  • Agile is a flexible methodology.
  • Agile is very accommodative to changes.
  • Agile methodology caters the ever changing requirements.
  • Its rapid delivery helps to satisfy customers.
  • There is no guesswork between development team and customer.
  • It includes continuous inputs from the client and face to face communication.
  • It is highly collaborative development process.
  • It is a continuous improvements process.
  • Requirements are expected to evolve and change in this process.
  • It has rapid deployment for work.
  • Its phases are well-processed and completed once at a time.
  • This process helps to measure the progress by the amount of completed work.
  • This is a constantly improving process since changes can be made during the process.
  • It helps you to deliver exactly according to client’s expectation.
  • It is easy to add up-to-date features in program at any time.
  • Project priorities are evaluated at the end of every sprint, which help client to add their feedback about product.
  • In Agile bugs are solved in each sprint, so there are very less chances that you face any error in the end of development cycle.
  • This methodology helps to launch program at any level.
  • Teams get self motivated due to cross functionality.
  • Tracing progress is very easy in this methodology.
  • Structured backlog helps to monitor progress.
Disadvantages of Waterfall Methodology
  • In waterfall one phase problems are never solved completely during that phase and in fact many other problems regarding a particular phase arise after the phase is signed off, which results in badly structured system.
  • This process did not allow you to implement any changes during the current development process.
  • Implementation can only be tested once you have completed the project.
  • This is not a good model for object-oriented and complex projects.
  • Waterfall is a poor development model for ongoing and long projects.
  • A high amount of risk and uncertainty is prevalent in waterfall model.
  • There are no chances for mistakes.
  • Some team members stay idle for long durations.
  • Waterfall depends of initial requirements, if these requirements are faulty then the whole project is failed.
  • In this methodology whole project is tested in the end. If a bug is found in testing then there are chances that whole team would have to start program from beginning.
  • It’s too much costly to make any changes in program.
  • It has lack of team management and team motivation.
  • Tracing progress is too difficult in this methodology.
  • Whole project is completes in a sequence, so there are no chances to launch program earlier.
  • Team is not utilized fully in this methodology, because work is already assigned.
  • It’s too hard to handle and complete complex and large programs using this methodology.
  • Usually this technique is costly due to replanning costs.
Disadvantages of Agile Methodology
  • If the project manager is not experienced, then project can become a large series of sprints, and come in late and over budget.
  • This is a less predictable process about projects output (final product isn’t defined clearly).
    It is very hard for the client to handover the project to any other Vendor for more development or any maintenance.
  • Final project can be different from initial plan.
  • Frequent complaints for every small reason can mentally disturb developers.
  • For the completion of project every team member should be open minded and communicative.
  • Product owner and scrum master is highly pressurised in this methodology.
  • Sometimes managing the backlog itself becomes too much.
Which is best Methodology: Agile or Waterfall?
Agile:

In Agile rapid production is more important than product quality. Client can change project scope. Final picture of project is not clear. This methodology is more useful when you have skilled developers, who can think independently and capable of adapting every tough project. Rapidly changing standards industries prefer to use this methodology.

Waterfall:
It is good If you have a clear picture of your final product and clients give their complete requirements. In this methodology quality is more important than speed.
(Reference : http://www.yodiz.com/blog/agile-vs-waterfall-differences-in-software-development-methodologies/)
 

Sushant Tarway

Active Member
Alumni
Scrum Master vs Product Owner Differences in skills, duties and responsibilities (Agile Methodology)
Scrum_Master_vs_Product_Owner_Differences_in_skills_duties_and_responsibilities_Agile_Methodology.jpg


Scrum Master vs Product Owner Differences in Agile Methodology (skills, duties and responsibilities)
Agile is a methodology to do work in the easy and convenient way. Scrum is the most famous agile methodology. Every Agile methodology consists of four main roles, which are

  • Product owner
  • Scrum master
  • scrum team
  • stakeholder
In scrum software development methodology, Scrum master and product owner are two main roles, which are responsible for separate areas of the project. Both are necessary for the project. In Agile methodology Scrum master is a bridge between product owner and development team.

Scrum doesn’t have project managers. Instead, the team is empowered. They’re responsible for the outcome, and they can manage themselves. The classic project manager ‘boss’ of the team isn’t needed in Scrum.



by Jeff Sutherland


Scrum Master (SM)
In Agile development methodology, Scrum Master cares about that how the team’s work. Increases team efficiency, motivate his team, spins, argues for changes that will ensure quality and timeliness.
Ensure observance of DoD. Thanks to the measured velocity know how much work will be done in the Sprint. Thanks to the care of the compliance with the quality we are sure that the system does not fall on the second day after the start. Thanks to his soft work well.

Scrum Master Skills:
The Scrum Master ensures that daily stand-ups are held at a fixed time every day for up to 15 minutes.



by Jeff Sutherland, The Power of Scrum


  • Scrum master coordinate with his team friendly to make an ideal team for agile development.
    Scrum master improve the product quality.
  • Certified Scrum master certification, would be an advantage but not necessary
  • He protects his team from any distraction and helps them to stay focused and follow agreed-upon rules for scrum meetings.
  • He helps PO to maximize ROI to meet his objectives through the scrum.
  • He removes barriers between from product owner and development team.
  • Scrum master accepts tasks and encourages his team to meet the deadline.
  • Scrum master is like a coach who helps his team to perform better.
  • He has the full authority all over the process.
  • Scrum Master shield the team from any interference.
  • Scrum master Cooperate with the Organization, to track the company’s progress and process.
  • He helps his team to understand self-management and cross-functionality.
  • A good Scrum master has a Project management, Engineering, Designing, Testing background and disciplines.
  • He provides constant guidance to his team.
Duties of Scrum Master
  • He facilitates his team for better creativity and try his best to improve the efficiency of the development team.
  • Scrum master is responsible for managing scrum process in Agile methodology, with the coordination of scrum team.
  • Scrum master has the responsibility to removes the impediments for the scrum team.
  • Scrum master arranged daily stand-up meetings, scheduled meetings, demo, facilitate meetings and decision-making processes in order to ensure quick inspection and proper use of adaptation process.
  • He helps product owner to make product backlog in good shape and make it ready for the next sprint
  • Most important part of SM job is to remove impediments.
  • Conduct retrospective meeting.
  • Organize and facilitate the sprint planning meeting
  • Act as safeguard for team
Product owner (PO)
The product owner is a demanding position in agile methodology, PO need to understand the clear vision of a product from the customer, end user or stakeholders point of view. The product Owner is responsible for managing the product backlog and product backlog visibility. He ensures the business value of the product.

Product Onwer Skills
First-time product owners need time, trust, and support to grow into their new role.



by Roman Pichler.


  • The Poroduct owner should know the business value of product and customers demanding features.
    He should be available to the development team for the consultation, so that the team can implement the features correctly.
  • Product owner needs to understand the feature/program from the point of view of end-user, not from the point of view of the developer.
  • In most organizations marketing is discussed on the sales level, product owner job is to facilitate marketing persons and guide them to make those goals achievable.
  • The Product owner is responsible for the product, from a business point of view.
  • Product owner has a vision for the perfect product.
  • His focus is on ROI (return on investment).
  • He assesses values, Develop cases,themes and epics to ensure that work focuses on product strategy
  • He solves problems, complete trade-off analysis and makes decisions to stay on business deliverable commitment track.
  • He expresses the voice of the customers.
  • He collaborates with stakeholders during the concept development and visioning of the product.
  • He works with project managers and technical leads to priorities and determines the scope for product development cycles.
  • The product owner is client’s voice. His job is to report ROI, product effectiveness and risk analysis.
  • Sometimes the product owner and the customers are same, but sometimes the customers are might be thousands/millions of peoples.
Duties of Product Owner
  • Product owner attends sprint demo and sprint planning meetings. Attending daily scrum is also recommended but it’s optional.
  • He ranks the product features so that development team can clearly understand them.
  • Product owner is responsible for forming a deadline for the project.
  • His duty is to defines requirements and priorities.
  • He is responsible for determining the release date and contents.
  • is responsible for managing and developing the product backlog. He prioritized backlog of user stories for implementation.
  • His job is to define epics/user stories to Agile development team.
  • He needs to make sure that user stories are explained well and alway in right priority in backlog. Backlog grooming meeting practice is conducted by the team of product owners, but it’s optional in some organizations.
  • Spend some time with the team to prioritize/groom the user stories with few team members. Not all need to be involved.
(Reference : http://www.yodiz.com/blog/scrum-mas...uties-and-responsibilities-agile-methodology/)
 

Sushant Tarway

Active Member
Alumni
ole of Scrum Master In Daily Stand Up (daily scrum, daily huddle, morning roll-call)
organik-2.jpg


1. Agile Scrum Master Role In Daily Standup, Daily Scrum meeting, Daily Huddle In Agile Methodology
In agile software development daily standup or scrum meeting is a common ritual for many teams, the daily stand-up meeting a.k.a “daily scrum”, “15 minutes meeting” is simple to describe
“The whole team meets daily for a quick status update, meeting take place standing in circle by answering three basic questions”

But, this short definition doesn’t describe the strength of this meeting, this import ritual if practice correctly can bring significant value to the teams. Let’s have a closer look to the daily standup meeting

We already covered the scrum master roles and responsibilities in our previous blog, This blog is to summarise the scrum master roles in daily scrum, daily standup meetings.

2. How to organise daily stand up, scrum meeting in agile methodology
2.1. Agenda for daily scrum, stand-up meeting
All team member should answer those following questions

  • What did you do yesterday ?
  • What is the plan for today ?
  • Any blocker in the work you are doing ?
3. Scrum Master Role In Daily Standup
  • Send recursive calendar meeting invitation
  • Send recursive calendar meeting invitation to all team member including product owner.
  • Choose the morning time which is suitable for every team member, as its good habit to start the day with daily standup, scrum meeting
  • Emphasis on punctuality
  • Soft penalties for being late, if any team member join the daily scrum late, ask him/her to put 1 $ in the pool, that can be used to buy some candies for team, its just a token to be punctual, shouldn’t be used to offend anyone.
  • Record all the problem, open questions, impediments and resolve it later.
  • Scrum master interrupt if discussion goes into detail level, as scope of this meeting is sharing information not discussing the problem or solution in detail.
  • Don’t delay the standup or daily scrum meeting if some team member arrive late at work
3.1. Example To Keep The daily Standup or Daily Scrum In Early Morning
If any team member can not join on early daytime, here is one real time example given by the agile coach.
One team member (Bob) computing from Germany to Switzerland for work, and he don’t get to work before 10:30 am, most of the team arrive to work around 9 am, scrum master decided to have a call at 9:15 am and include him via the phone call remotely, as train passes through various tunnel so mobile reception is sometimes bad, Bob fond a suitable time spot in his commute when mobile reception is good, so he propose to move the daily scrum from 9:15 to 9:30 am, in that way team don’t have to wait until 10:30 am or later to start the meeting.

4. Duration and style of daily standup or daily scrum meeting

  • 5-15 min
  • Team should be standing up in circle, team members go one by one to answer the above three questions.
  • No detail discussion
5. Participants Of Daily Stand up or Daily Scrum Meeting
  • Product Owner (Optional)
  • Team members
  • Scrum Master (Facilitator)
6. Purpose Of Daily Standup or Daily Scrum Meeting
  • Identify as a team
  • Sense of sharing common goal
  • Increase team synergy of coordinated effort
  • Working together toward solving problem and improvements
  • Representative from various areas (SW, Testing, DB, UI, marketing, sales,etc) contributing status and progress.
  • Resolving problem before it become significant serious impediment
  • Don’t limit the meeting to ” i did this…” , “i did that ..”, improve the standup meeting effectiveness of communication, keep the meeting shorten to an optimal length.
  • Time the meeting, qualitatively judge how long the meeting should take, as it various on the team size, but 15 min is a good duration for team size of 6-8 team member
  • Take it off-line, don’t solve the problem in daily standup meetings.
  • Safety net for the team, stand up is the place to raised concern, problem, improvements that can be discussed in detail after the standup
Reference : http://www.yodiz.com/blog/role-of-s...p-daily-scrum-daily-huddle-morning-roll-call/
 

Sushant Tarway

Active Member
Alumni
Agile Manifesto 12 principles explained for SW development (Part 1)
agile-manifesto-explained.jpg

Agile Manifesto

Agile manifesto 12 principles of software development, is published around 15 years ago, it is the simplest and minimalistic approach to give power to the scrum team, give competitive advantage to customer, engage the ends like business and development team, it harness agility and welcome change, emphasis on shorter and consistent releases for active feedback loop, bring motivation, trust and respect for individual. Which in return deliver valuable and working software earlier and faster.

Agile manifesto is not a recipe, manifesto idea is to create “master chefs”, which can bring about perfect dishes with any available ingredients during any circumstances.

These are the roles defined in 12 principles of agile manifesto for SW development.

Team[Developer] → Business People → Customer[Sponsors] → End User

Agile Manifesto explanation
Lets have a detailed look at all the agile manifesto principles and explain each principle.

1. Agile Manifesto Principle 1
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

1.1 Important takeaway (agile manifesto explanation)
  • highest priority
  • satisfy
  • customer
  • early
  • valuable
It is interesting to see that 1st principle of agile manifesto starts with words

[Our] & [highest Priority] & emphasising the [customer satisfaction] in same sentence.

[Our] define here as a team, it put the responsibility for customer satisfaction to scrum team.

[early deliver] deliverable should be early. Which means we need to divide the deliverable into smaller pieces, that can be delivered earlier to customer. As it shortens the feedback loop, which help us to understand what customer really want. This principle also emphasises the value in our delivery for our customer. Delay in delivery and not-valuable product will delay the feedback from the customer, which can delay the whole product.

[continuous delivery] delivery should be early and continuous, so feedback between team and customer should be continuous on each delivery.

[valuable] emphasis on “value” then a release. We need to ask our selves if we truly delivering the value which we promised and committed with the customer.

2. Agile Manifesto Principle 2
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

2.1 Important takeaway (agile manifesto explanation)
  • changing
  • even late
  • competitive advantage
  • customer’s
[changing] this principle emphasise on being agile with its true essence, welcoming the change for the customer requirement. it emphasises that requirement is very dynamic and live element, which grow and shape up to be a real product, this is one of the concept differ heavily from its waterfallish approach.

[late] it’s never too late for customers to do changes in the requirement. To avoid those changes to happen late in requirement cycle, it is best to spend more time with the customer to understand it well in first place, it goes back to principle 1, of releasing early and in small iteration continuously.

[competitive] scrum team enhancing the competitiveness of customer, this competitive advantage could be in terms of cost, feature offering, etc for the customer towards its competitors.

3. Agile Manifesto Principle 3
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

3.1 Important takeaway (agile manifesto explanation)
  • Working Software
  • frequently
  • shorter timescale
[working software] this principle doesn’t just emphasise on delivery but actually on “working” software, the delivery which conform of DoD[definition of done], CoS[condition of satisfaction] and value of its own, as describe in principle 2

[shorter timescale] delivering earlier, with preference on shortening the timescale, as this is the main philosophy of eliminating waste, to keep track on timeline of deliverable

4. Agile Manifesto Principle 4
“Business people and developers must work together daily throughout the project.”

4.1 Important takeaway (agile manifesto explanation)
  • must work
  • together
  • throughout
[Business people] is referred to a Product Owner, or anyone who is a proxy between customer and team.

[must work together] emphasise here to have a shared responsibility and accountability, ‘work together’ stresses on total commitment on both sides.

[throughout the project] this principle emphasise that there should be a commitment, direct collaboration and cooperation in all the phases of a project.

5. Agile Manifesto Principle 5
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

5.1 Important takeaway (agile manifesto explanation)
  • Build projects
  • motivated individuals
  • support in need
  • trust
  • done
[motivated individuals] agile manifesto, speak too highly about scrum team, this principle talked about motivation and happy individual.

How you create a motivated individual?
the answer is simply provided in another half of the principle

“.. Give them the environment and support they need, and trust them to get the job done.”

Start with a value, show by action that product team is going to build a which have high value for the end customer.

  • Let the team come up with commitment and delivery plan which they feel comfortable with.
  • Let them execute, don’t come in their way.
  • Remove the hindrances which come on the way to the team.
  • That give them trust and motivation to deliver working software with value.
6. Agile Manifesto Principle 6
“The most efficient and effective method of conveying information to and within a development team is the face-to-face conversation.”

6.1 Important takeaway (agile manifesto explanation)
  • efficient
  • effective
  • conveying
  • face-to-face
[efficient and effective] this principle emphasis on efficient and effective communication over status meetings, just like we do during a daily scrum, it’s an act of conveying information.

[face-to-face] effectiveness of a meeting is if it is face-to-face. Just like daily scrum and sprint planning, manifesto doesn’t dictate how the meeting should be run, it emphasise on its effectiveness and efficiency.
(Reference : http://www.yodiz.com/blog/agile-manifesto-12-principles-explained-for-sw-development-parti/)
 

Sushant Tarway

Active Member
Alumni
Agile Manifesto 12 principles explained for SW development (Part II)
Agile-Manifesto-partII.jpg

Agile Manifesto 12 principles Explained

This is the part II of our previous post, for the explanation of first six principles of agile manifesto check this post.

Agile measure the progress of team or organization primarily by its software or product that works. Deliver software that sustain and scale, it educate the team to be self-organized and have constant and sustainable pace indefinitely. Organization or team focus more or technology excellence, good design, and agility. Essentially reducing the unimportant tasks and limiting work in progress is important.

Empower the team so it will deliver the best design, architecture and quality software. Self-organize team doesn’t just deliver a quality software, it regularly tune and adjust to itself, applying change management to itself for improvement

Agile Manifesto Principle 7
Working software is the primary measure of progress.


Important takeaway (agile manifesto explanation)
The most important measure for business should be working software. As a happy customer is a result of working software, instead of focusing in unnecessary QA, sales and productivity metrics we should measure on value, listening to customer satisfaction, as this is what defined to be a working software. This also tells how well is the progress of the team.

Agile Manifesto Principle 8
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.


Important takeaway (agile manifesto explanation)
[Sustainable development] [constant pace]


The important reason of team so hurry in adopting agile is to have sustainability and scalability in their product, as it just cut through the waste. Making everyone to work with constant pace continuously, meaning with in with fixed set of scope to achieve it, collectively as a team of sponsors, developer and manager.

Agile Manifesto Principle 9
Continuous attention to technical excellence and good design enhances agility.


To gain agility, we should give more emphasis on design and technical excellence as nothing else really matters.

Agile Manifesto Principle 10
Simplicity — the art of maximizing the amount of work not done — is essential.


Important takeaway (agile manifesto explanation)
It’s essential and simple to identify the amount of unimportant work and eliminate it to have a clear visibility for team, it’s reducing waste, removing impediments and limiting work in progress, but its a art which should be learn by doing it.

Agile Manifesto Principle 11
The best architectures, requirements, and designs emerge from self-organizing teams.


Self organized team deliver the best architecture, fully refined requirements and design, team here is a project team which includes dev team, product owner, scrum master and stakeholder.

Agile Manifesto Principle 12
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Important takeaway (agile manifesto explanation)
Apply the improvement process activities like the retrospective and other activities more often. Self-organise team tune to itself and do the sanity check regularly. As project situation and realities keep changing, it’s not only process improvement but the team need to adjust its behavior to any change circumstance. Assuming that sprint scope keep on changing, it could be frustrating, but the team needs to understand that those changes are directly coming from customers, it affect heavily on the value proposition and revenue stream.

(Reference : http://www.yodiz.com/blog/agile-manifesto-12-principles-explained-for-sw-development-partii/)
 

Sushant Tarway

Active Member
Alumni
Scrum roles (scrum methodology)
1. Scrum Roles in Scrum Methodology
Scrum-roles-in-scrum-methodology.jpg

In scrum methodology the important aspect is scrum roles. It is important that how those scrum roles are assigned and responsibilities are shared. As scrum roles are all about commitment. Scrum roles provide the best composition of a team. Which distinguished it from other SW development processes.

1.1 Scrum Methodology
In Scrum Role, there should be a clarity and clear division of roles and responsibilites

Here are few aspect of scrum roles
When it comes to commitment, authority and team size in general

Chicken and the Pig
Total commitment – Chicken and pig decided to have a bed-n-breakfast restaurant. The pig then replies, “no way … you’d only be involved, but I’d be committed!”

Two Pizza Rule
Highly autonomous task forces with five to seven people. No more than can be fed with two pizzas, who innovate and test new features. Jeff Bezos CEO Amazon

Having Two Scrum Roles (Scrum Master and Product Owner) in Same Project


Two pizza rule [Jeff Bezos] : In scrum don’t exceed the team size, if they couldn’t be fed with two pizzas


Click to Tweet

When it comes to adopting scrum. It is important for a prospective scrum team to know exactly what they are signing up for. Agile team is a cross functional group of individuals, who has the ability and authority. Which help them to define, analyse and build, In a short iteration time-box the sprint.

As such the team includes developers, tester, scrum master, product owner, and other resources such as UX, architect, sales and marketing. Scrum team have collective responsibilities to deliver the valued output which they commit to.

Team operate in context of the mission, and mission is defined in each sprint which is time boxed, each individual is doing her/his part. Working on collective or individual items, sharing the problem and progress among team.

2. Scrum Roles and Responsibilities
Core values of scrum team are collaboration, functional software delivery , self management, and flexibility to adapt to emerging business realities.

Adopting scrum for any team, is not just a matter of getting used to new processes. Some times it may come as a culture change. Team members may find difficult in accepting and adjusting to the roles. Those are the main agile roles which together decide and define the fate and destiny of a project.

Agile project teams are made up of many people and include the following scrum roles.
3. Scrum Roles

  • Scrum Master
  • Product Owner
  • Scrum Team
  • Stakeholders
scrum1.jpg


4. Scrum Master
[Tweet “In agile, Scrum Master is the top dog with no authority”]

The Scrum Master is primarily the facilitator for the team, top-dog with no authority for the Product owner. The role of the Scrum Master is to remove all the impediments and any problem faced by team in day-to-day work, make the adoption of a scrum smoother and fun for the team or in some case enforce the scrum ceremonies and processes.

Since Scrum Master is the center of gravity for the things related to sprint scope and scussess. S(He) the primary source of knowledge for all things related to the sprint.

However, the Scrum Master is only a facilitator and has limited authority over the team in the sense that he/she cannot commit to goals and deadlines on behalf of the team or from stakeholders. It is up to the team to decide how much work can be committed in one sprint. The Scrum Master can also be seen as an impediment remover for the team, who is there to remove any obstructions that the team may face in pursuit of its sprint goals.

Responsibilities of the Scrum Master may include:

Product-Owner.jpg


5. Product Owner
[Tweet ” In scrum, authority comes with accountability and responsibility.”]

In Scrum, the Product Owner is the one who convey the vision of stakeholder(s) to the team. Product owner has the ultimate authority to alter the scope, influence the development effort and prioritize work for the scrum team.

He is the voice of stakeholder, which make him/her also the single chocking neck if something goes wrong. Which means he is the responsible person for delivering which was committed in time and with quality. In scrum authority comes with accountability and responsibility.

The product owner prioritizes backlog for the team. However Product Owner should respect the commitment of team for delivering what team feels comfortable. The team is ultimately responsible for defining how much can be achieved within a sprint. That should be clearly communicated to the stakeholders by Product Owner.

5.1 Responsibilities of the Product owner

  • Create the Product backlog.
  • Sort the Product backlog items according to priority.
  • Create and maintain the Release Burndown Chart.
  • Provide support for the Scrum Master. Help the Scrum Master organize Sprint Review Meetings.
  • Attend daily scrum (optional).
  • Attend sprint planning and sprint demo meetings.
  • Clearly communicate the business requirements to the Team.
  • Build and maintain a relationship with the Stakeholders, including reporting to stakeholders regularly.
Scrum-Team.jpg


6. Scrum Team
[Tweet “Commitment means, Scrum Team will deliver the agreed results on time”]

The Scrum team is responsible for working towards meeting their sprint goals and delivering their work on time. For this to be accomplished, team works with the Scrum Master which items from the Product backlog can be delivered in a Sprint. Since the team has made a commitment to a Sprint, they must ensure that they can deliver the agreed results on time, as sprints cannot be extended or delayed. In this manner, the team holds great power, however is also ultimately held accountable for delivering on time.

6.1. Scrum Team Responsibilities

  • Self-organize and Commit to a Sprint Goal.
  • Work with Product Owner to decide which items from the Product Backlog will be completed in which sprint.
  • Help create and maintain the Sprint Backlog, Sprint Burndown Chart and Task Board
  • Implement the findings that result from Retrospective meetings.
  • Create and follow the Definition of Done
  • Attend all Scrum meetings, including Daily Standups.
  • Look for and suggest ways to continuously improve their processes.
Scrum-Stakeholders.jpg


7. The Stakeholders
The Stakeholder by definition is anyone who has an interest (or a stake) in the project. This may refer to people who provide funding for the project or they may be direct managers of the team members. In the Scrum environment, the stakeholders are responsible for communicating their needs, and providing feedback to the team. In scrum roles stakeholder is the highest entitle to make the final decision when comes to priority and delivery

7.1 Stakeholder Responsibilities

  • Develop and Maintain the Product backlog along with the Product Owner.
  • Attend the sprint demo meetings.
  • Provide feedback to the product owner.
  • Prioritize work affectivley with product owner
(Reference : http://www.yodiz.com/blog/scrum-methodology-scrum-roles/)
 

Sushant Tarway

Active Member
Alumni
User Stories Acceptance Definition and Criteria in Agile Methodologies
Acceptance-Criteria-user-stories-agile-methodologies.jpg

Definition of Acceptance Criteria in Agile Methodologies for user stories

The terms ‘Conditions of Satisfaction’ and ‘Acceptance Criteria’ used interchangeably.

They can be considered a clear description that will define value proposition, user flow or characteristic of the solution.

Acceptance criteria are acted as a catalyst for test cases and it should be testable. Acceptance criteria provide a detailed scope of the requirement, which help the team to understand the value and help the team to slice the user story horizontally.

The condition of satisfaction help to set expectations within the team as to when a team should consider something done. It helps the team to break down the user stories in task(s), if acceptance criteria are defined in detailed, then the team can provide better effort estimation for a user story, so development cycle can be shorter, resulting in no waste.

How to write acceptance criteria for a User Story in Agile?
The acceptance criteria is a must have ingredient for a user story. Acceptance criteria is a checklist that determine if all the parameters of a User Story and determine when a User Story is completed and working.

Before the developer can mark the User Story as ‘done’. All criteria must be fulfilled so that it is ensured that the User Story works as planned and tested.

The product owner is usually responsible for specifying what the acceptance criteria should be for each of the user stories.

When crafting perfect user story, acceptance criteria make the functionality pretty transparent, it help the product owner to find any missing point and validate the assumption. If any assumption is incorrect it helps to catch a little sooner.

Agile Acceptance Criteria Template
There is no template from the scrum about acceptance criteria, acceptance criteria is a detail description of system or feature put forward by the product owner, it’s a criterion against which the user story should be validated and tested.

What Acceptance criteria should be included

  • Negative scenarios of the functionality.
  • The impact of a user story to other features.
  • UX concerns
  • Functional and non-functional use cases
  • Performance concerns and guidelines.
  • What system/feature intend to do
  • System of feature doesn’t do anything, isn’t supposed to do
  • End-to-end user flow
What Agile Acceptance Criteria Should Not Include
Do not include following obvious stuff as your acceptance criteria for your user stories

  • Code Review was done
  • Non-blocker or major issues
  • Performance testing performed
  • Acceptance and functional testing done
Above checklist need to be included as part of DoD (definition of done), which serve as a checklist for overall sprint process, those shouldn’t be part of acceptance criteria

How to Write User Stories & acceptance Criteria
Acceptance criteria should be expressed very clearly, in simple language, without any ambiguity about the expected outcome. This ensures that the testers will be successful when they take the acceptance criteria and translate it into manual or automated test cases.

Simple and widely accepted format of user story template is

As a ____, I want ___, so that ____

Practical Example of User Story With Acceptance Criteria
user-story-template-example-1.jpg

Here is the detailed example of our user story with acceptance criteria

Example bellow is an implementation of a new feature called printing. This feature provides the user with printed format of a user story or a bug in presentable format

Practical example of acceptance criteria
“As a user I should have the option to print any item with all the details, comments, and other things. I should get printable view in browser and then should have the option to print into different formats”

Acceptance Criteria
  • All the item information should be visible including title, ID, description, comments, attachment names, linked items tasks/issues/epics etc, associated items, dependencies etc
  • On the preview page, I should option to print, download as
  • PDF
  • Word
  • XML(optional)
  • any other?
All the items type should be printable

  • User Story
  • Epic
In case of Epic, we will show the related user stories and show only, ID, Title, Responsible, Status and priority

  • Tasks
  • Issues
It should be possible to print the item details from almost anywhere, e.g.,

  • From boards widgets under context menu
  • In case of Epic or user story, from Epic or Backlog item context menu
  • From item detail view
  • From pop-up under context menu
(Reference : https://www.yodiz.com/blog/which-house-of-cards-character-are-you-in-your-agile-team/)
 

Sushant Tarway

Active Member
Alumni
What Is Epic In Agile Methodology (Definition & Template of Epic)
epic-user-story-agile-methodology.png


1. Epic Definition in Agile Scrum Methodology
An Epic can be defined as a work, which can not be completed in a week time, or any work which will take a full sprint to complete. By observation 5-10 user stories comprise of one Epic in agile methodology.

2. What is epic mean in agile methodology
The Basic unit of work defined in Scrum is User story. But very often it happens that, when Product Owner which writing a user story for a feature or customer request, it become so big that it can not fit either in a week or a sprint time-frame. Then Product Owner starts slicing that big user story in smaller user stories, so that can be assigned to a developer in a sprint, estimated well for its work effort.

3. How Epic used in Agile SW Development
In some organizations, there is common practice that each of the bigger customer request, feature or requirement is considered as Epic, how you define “bigger” work varies from organization to organization. Some organization uses theme or scope approach, they created Epic for different focus area of the project and all the new requirement is mapped to that focus area of Epic, this will make tracking of the specific work area of a project easier.

Rule of thumb is, if there are more than 5 user stories, of same focus area in a project, then it’s good to create an epic and attach all five of those user stories to that Epic.

4. How to Track epic
Epic is a good way to track your bigger features, remember that epic is just a placeholder which can hold multiple user stories which are focused on specific scope, think of epic as a book and user stories are its’ chapters.

Since epic is a just a placeholder, User stories from an epic can be spanned across multiple projects. Normally it takes few sprint to finish one Epic, Product Owner can easily determine the percentage complete of an epic by calculating the percentage of user story done in each sprint for each of the epics.

5. Epic Example in Agile Scrum Methodology
Let’s take an example of Epic, assuming we need to improve the feature of our backlog in our Yodiz tool.

We received three requests from our beloved customer regarding our backlog.

Hello

I want to reorder my user stories in backlog. Currently, it’s not possible. Some star value will be good to have, so I can group my user stories in backlog. It will also be good to see the sprint value in backlog

Best Regards
Yodiz Customer


6. Agile Epic Sample
So after a detailed meeting with the customer, Produced owner ended up writing following user stories. Since the scope of work is backlog, he created an epic and linked all user stories under that epic

  • Epic 01: Provide options to user to manage backlog easily
  • User Story 01: As a release manager, I want to have my releases mapped to different sprints, so I could visualize easily
  • User Story 02: As a system admin, I should be able to provide rights who can prioritize product backlog
  • User Story 03: As a user I should be able to re-order my backlog using numbered items, star priority or simple drag n drop
7. User Story Template in agile Methodologies
In the screenshot from Yodiz above, you can see the Epic EP-3 which has the status In Development. The Epic is further subdivided into smaller user stories, US-4, US-6 and US-7.

epic-in-agile-methodology-template-example.jpg


The Detailed view of the Epic above shows us the status, priority and estimates and owner of each of the individual user stories.

Burndown charts can be used to give a visual representation of Epics. This keeps the development team motivated and the Stakeholders informed. It shows clearly how much progress the team is making as well as where work was added or removed by the Product Owner. This constantly keeps everyone on the same page
(Reference : http://www.yodiz.com/blog/what-is-epic-in-agile-methodology-definition-and-template-of-epic/)
 

Sushant Tarway

Active Member
Alumni
The Agile Development Life Cycle
The Agile development life cycle is essentially different from more conventional development cycles, in that it is a constantly ongoing process instead of a one stage at a time, step by step process of development. For instance, in a more traditional development life cycle each individual stage may be completed with a high investment of effort, in detail and in order. However, in the Agile development life cycle only the initial stages of Planning and Analysis require that high level of commitment. To get a better grasp of things, let's have a look what a more traditional process might look like:



In comparison, an Agile development lifecycle may look something like this:



As can be seen above, the agile development cycle is a very dynamic process. After the initial Planning and Analysis stages are over, most of the work happens in between Sprints. A Sprint is an agreed upon duration of time in which the team works on various features. The duration of the Sprint depends on the preferences of different teams. What can also be observed is that the software is released in increments, with a release usually happening at the end of a Sprint. This dynamic work model allows Agile teams to bypass the problem of delivering a product that does not meet the end users requirements.

Customer feedback can be used to constantly improve upon the project, and to provide the correct product to the end user. To sum it up, it needs to be mentioned that this development life cycle is highly adaptable in any work or project development environment, and is not exclusive to the software industry due to its process visibility at all stages. However, there are some drawbacks to this approach. Most notably the process of documentation gets left behind. Due to the constant real time nature of completing work in Agile keeping detailed logs of documentation becomes difficult. Secondly, the immediate feedback gathered from end users can sometimes become a burden on the team. When the end users get used to getting their requirements met instantly, the demands for new features are bound to increase. This can sometimes swamp the development team and put too much on their plates at once.
(Reference : https://www.yodiz.com/blog/the-agile-development-life-cycle/)
 

Sushant Tarway

Active Member
Alumni
Agile Scrum Process Explained in 12 Steps
This blog is created in effort of explaining all major aspect of scrum process. The process is divided into 12 steps, which are explained below.



Steps 1 & 2: User Story Writing and Estimation


Story Estimation


Steps 3 & 4: Story Prioritization in the backlog

Step 5: Release Planning


Step 6 & 7: Sprint Planning & Task Creation Process


Step 8-12: Sprint Iteration

(Reference : https://www.yodiz.com/blog/agile-scrum-explained-in-12-steps/)
 
Last edited by a moderator:

Sushant Tarway

Active Member
Alumni
Product Backlog vs Sprint Backlog Difference In Agile Methodology
product-backlog-vs-sprint-backlog-agile-methodology.jpg


Product Backlog VS Sprint Backlog difference In Agile Methodology
1. What is a Product Backlog
The product backlog is a priority list of user requirements, use cases to be done in order to create, maintain and sustain a product. Product Owner owns the product backlog,(s)he is the one who prioritize it based on the customers feedback or business value. For details about how to write user stories, template, examples and acceptance criteria are already covered in our previous blog

1.1. Characteristic of a Product Backlog
  • It is a very active document where all the wishlist and user requirements are gathered
  • Product owner makes sure that content of product backlog “user stories” are defined in detailed level
  • user story in product backlog should be enough in sizing to be fit in one sprint
  • All aspects like use case scenarios, condition of satisfaction aka acceptance criteria should be provided in each of the user stories
  • The product backlog acts as an input to the sprint backlog when comes to functionality
  • There are also bugs/issues, epic, user stories and themes are included in the product backlog
  • There are also bugs/issues, epic, user stories and themes are included in the product backlog
  • To put it short: The product backlog is the wish list for the product for the whole lifecycle. It defined with its detail nature what to be implemented.
1.2. Techniques Used To Maintain Product Backlog Effectively
1.2.1. DIVE

Product backlog items are prioritized in linearly ordered based upon DIVE criteria

  • Dependencies – keep it linear with fewer dependencies with other user stories, epic or themes. It’s OK to have horizontal dependencies.
  • Insure against risk (business and technical)
  • Business Value
  • Estimated Effort
1.2.2. DEEP
  • Detailed
  • Estimated
  • Emergent
  • Prioritized


1.2.3. INVEST


  • Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
  • Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
  • Valuable A user story must deliver value to the end user.
  • Estimable You must always be able to estimate the size of a user story. Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  • Testable The user story or its related description must provide the necessary information to make test development possible.
2. What is sprint backlog
There are also bugs/issues included in the sprint backlog for each sprint.

Sprint backlog is the subset of the product backlog. Each sprint, scrum team picks the user stories from product backlog on top of its stack, the number of user story picked by scrum team for a time box sprint is based on the average velocity of a scrum team. Product Onwer set the sprint’s goal for the team, scrum team pick the user stories from product backlog fulfilling those goals. Those user stories which moved to sprint is owned by scrum team, as the team is committed with the sprint backlog items during a sprint which is in timebox.

2.1. Characteristic of a Sprint Backlog
  • Sprint backlog is dynamic in nature,each sprint the above scenario is repeated. Good practice is to keep the sprint backlog aka sprint goal as static as possible during a sprint.
  • During each sprint planning session, the team returns back to product backlog to pick recently prioritized user stories for the sprint.
  • Sprint backlog is a subset of product backlog
  • Sprint backlog is an output of a sprint planning meeting.
  • In Sprint backlog, scrum team works on how the user stories would be implemented in a sprint by dividing it further into tasks and estimating it.
  • Assuming Product Backlog has stories: 1, 2, 3, 4 , 5 and 6. The team decides to do stories 1,2 and 4. As during sprint planning team realized that there still some question which is not answered well by the Product Owner, so they decided not to include the user story no: 3 and jump to user story no:4, which was defined well.
  • Sprint backlog is owned by the Development Team and contains what and how it get’s delivered
  • Lastly in sprint backlog team implementing (converting) the most prioritized product backlog items into working software. For each iteration (sprint) the team creates a new plan, based on what is in the top of the Product backlog when starting the sprint.
 

Rakesh Deshpande

Moderator
Simplilearn Support
Product Backlog vs Sprint Backlog Difference In Agile Methodology
product-backlog-vs-sprint-backlog-agile-methodology.jpg


Product Backlog VS Sprint Backlog difference In Agile Methodology
1. What is a Product Backlog
The product backlog is a priority list of user requirements, use cases to be done in order to create, maintain and sustain a product. Product Owner owns the product backlog,(s)he is the one who prioritize it based on the customers feedback or business value. For details about how to write user stories, template, examples and acceptance criteria are already covered in our previous blog

1.1. Characteristic of a Product Backlog
  • It is a very active document where all the wishlist and user requirements are gathered
  • Product owner makes sure that content of product backlog “user stories” are defined in detailed level
  • user story in product backlog should be enough in sizing to be fit in one sprint
  • All aspects like use case scenarios, condition of satisfaction aka acceptance criteria should be provided in each of the user stories
  • The product backlog acts as an input to the sprint backlog when comes to functionality
  • There are also bugs/issues, epic, user stories and themes are included in the product backlog
  • There are also bugs/issues, epic, user stories and themes are included in the product backlog
  • To put it short: The product backlog is the wish list for the product for the whole lifecycle. It defined with its detail nature what to be implemented.
1.2. Techniques Used To Maintain Product Backlog Effectively
1.2.1. DIVE

Product backlog items are prioritized in linearly ordered based upon DIVE criteria

  • Dependencies – keep it linear with fewer dependencies with other user stories, epic or themes. It’s OK to have horizontal dependencies.
  • Insure against risk (business and technical)
  • Business Value
  • Estimated Effort
1.2.2. DEEP
  • Detailed
  • Estimated
  • Emergent
  • Prioritized


1.2.3. INVEST


  • Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
  • Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
  • Valuable A user story must deliver value to the end user.
  • Estimable You must always be able to estimate the size of a user story. Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  • Testable The user story or its related description must provide the necessary information to make test development possible.
2. What is sprint backlog
There are also bugs/issues included in the sprint backlog for each sprint.

Sprint backlog is the subset of the product backlog. Each sprint, scrum team picks the user stories from product backlog on top of its stack, the number of user story picked by scrum team for a time box sprint is based on the average velocity of a scrum team. Product Onwer set the sprint’s goal for the team, scrum team pick the user stories from product backlog fulfilling those goals. Those user stories which moved to sprint is owned by scrum team, as the team is committed with the sprint backlog items during a sprint which is in timebox.

2.1. Characteristic of a Sprint Backlog
  • Sprint backlog is dynamic in nature,each sprint the above scenario is repeated. Good practice is to keep the sprint backlog aka sprint goal as static as possible during a sprint.
  • During each sprint planning session, the team returns back to product backlog to pick recently prioritized user stories for the sprint.
  • Sprint backlog is a subset of product backlog
  • Sprint backlog is an output of a sprint planning meeting.
  • In Sprint backlog, scrum team works on how the user stories would be implemented in a sprint by dividing it further into tasks and estimating it.
  • Assuming Product Backlog has stories: 1, 2, 3, 4 , 5 and 6. The team decides to do stories 1,2 and 4. As during sprint planning team realized that there still some question which is not answered well by the Product Owner, so they decided not to include the user story no: 3 and jump to user story no:4, which was defined well.
  • Sprint backlog is owned by the Development Team and contains what and how it get’s delivered
  • Lastly in sprint backlog team implementing (converting) the most prioritized product backlog items into working software. For each iteration (sprint) the team creates a new plan, based on what is in the top of the Product backlog when starting the sprint.
@Sushant Tarway Good inputs. Much Appreciated your work! It would be great if you can put the data into the word docs/docx and shall post.
 

Rakesh Deshpande

Moderator
Simplilearn Support
Hello Participant,

Here are some files which might help you.
 

Attachments

  • FAQ AGILE SCRUM MASTER.PDF
    102.2 KB · Views: 4
  • english_sample_exam_asm_201504.pdf
    359 KB · Views: 3
  • english_preparation_guide_asm_201504.pdf
    427.7 KB · Views: 2

Rakesh Deshpande

Moderator
Simplilearn Support
Hello ,

This week, Let's understand how to work on JIRA Tool :

1. You gonna create a free account with the link shared to your registered Email ID.
2. Please note the URL while you enter during Claim your Site section. That will be the one where you will login to work on the project.
3. Once done, Login and explore more about the JIRA cloud Tool.
4. Do not rush to start working on the project, take time - create a dummy project-create some issues, Create sprint and set to release. This you can do to multiple projects before you actually work on the project. Once you're done- Check the Reports which shows the performance on the project.

Hope this helps!
 

Rakesh Deshpande

Moderator
Simplilearn Support
It's time to know about Scrum !

Q: Why is it called Scrum?
A :When Jeff Sutherland created the scrum process in 1993, he borrowed the term "scrum" from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by Rugby teams.
 
Top