Mastering Agile Achieve complete agility with Eijel
Dondon Vizcayno Founder of Eijel
Copyright © 2014 by Dondon Vizcayno
All rights reserved. No part of this book may be reproduced in any form or by any electronic or mechanical means, including information storage
and retrieval systems, without permission in writing from Dondon Vizcayno, except by a reviewer who may quote brief passages in a review.
First Edition
Contents 5 Introduction 6 What You Will Get 7 The Incompleteness Chasm 8 The Ladder 9 Achieve Complete Agility
10 A Sample Project 11 Client Needs A Website 12 And Also Mobile Apps 13 Meet the Project Plan 14 Embracing Agile Development
15 Eijel 16 An Anchor to Reality 17 Creating Your Account 18 Creating Your Projects
20 Project 21 A Context for Everything 22 When a Project is Deleted
23 Sprints 24 Managing all the Sprints 26 Updating and Deleting Sprints
27 Scrum Team 28 Building Your Team 30 When Members and Roles Change
31 Product Backlog 32 What Needs to Be Delivered 34 Reorganizing the Priority 35 Assigning Points and Playing Poker 39 Viewing the Burndown Chart
40 Wiki 41 Maintaining Living Documents 43 Uploading Images
44 Sprint 45 How Much Work Can Be Done? 48 Doing the Actual Work 52 Progressing the Tasks 54 Closing a Sprint 56 Viewing the Burndown Chart
57 Bug Tracker 58 Managing Project Defects
61 Software Engineering 62 Serve the Developers 63 The Value of Quality Code
64 Conclusion 65 A Promise Kept 66 Succeeding in Your Projects
Introduction
What You Will Get
The Incompleteness Chasm
The Ladder
Achieve Complete Agility
What You Will Get
I promise you three things
In reading this book I promise you will get three things:
1. You will know how to do agile.
2. You will know how to achieve complete agility.
3. You will know how to master agile.
And if you give effort in doing item 1 above, I will give you a fourth promise:
4. You will succeed in doing all items above. You will achieve mastery.
The Incompleteness Chasm
Why companies fail at agile
The incompleteness chasm is the main reason why many companies fail at agile.
It is the gap that separates companies successfully doing agile from those trying
and yet failing to get into it. It is something that must be crossed, or the company
will fall short in its transformation and will revert back to its old ways.
You will need a ladder to cross this chasm. The ladder represents a solution to an
incompetency:
1. Companies don’t know how to do agile. They have an idea, but it is flawed.
2. Even when trained, they can’t relate what they have learned to what they
are currently doing.
3. The training will fade like a dream. It is over and trainees will go back to
their jobs bringing a story of an ideal world called “agile”. It won’t change
anything after wards though.
4. And if and when the company finally gets what agile is, it overwhelms
them. They can’t transform. The current is always easier.
5. Companies rarely hire agile coaches. But trainings don’t help them either.
Companies don’t know what to do, and if they know, they don’t know how to do
it.
The Ladder
A ladder to cross the incompleteness chasm
A company successfully doing agile is separated by a mindset and a collection of
practices from another company that fails at it.
This is the chasm that the failing company must cross. How can it get the mindset
and the set of practices present in the other company?
What is the ladder it can use to cross the incompleteness chasm?
Should it hire an agile coach, send the team into more training?
My answer is simple.
I introduce to you Eijel. Eijel is a tool that will empower you to have the mindset
and the practices to emulate the companies successful at agile.
Eijel is a ladder that will help you cross the incompleteness chasm.
Why?
Because it will help you achieve complete agility.
Achieve Complete Agility
A complete solution for doing agile
When a company crosses the chasm and becomes good at agile, it achieves
complete agility. It achieves the minimum to be really good at something. It has
completed the requirements. And with time and practice, becomes master at it.
The requirements for a company to achieve complete agility are:
1. It knows the principles and values behind agile. This is the why of agile.
2. It knows the practices of agile and knows how to do them in real life. This
is the how of agile.
3. It has the will of really following the principles and really doing the
practices.
4. It is doing its best to implement this will, no matter how imperfect.
5. It aims to excel and master the execution of the will.
The will of agile can have a physical manifestation. A concrete embodiment that
represents the abstract concept.
The will of agile is the ladder that helped the company cross the chasm.
The will of agile, in this book, is represented by Eijel.
The next chapter will introduce the context in which you will learn complete
agility.
A Sample Project
Client Needs A Website
And Also Mobile Apps
Meet the Project Plan
Embracing Agile Development
Client Needs A Website
Learning with a goal
It is best to learn new things by solving a problem using the lessons as a solution.
I will give you a client with a project that needs to be delivered using agile.
The client, Urela, is a start-‐up that collects promotions of different shops and
provides them to users through its mobile apps and website. The users will be
categorized as publishers, consumers, and admins.
The publishers will use the website for posting their promos. They can select the
specific shops that provide the promotion and set the start date and end date
when the promotion is valid. They can also set the title, the details, and the image
for the promo.
The client demands that the website be operational after 3 months.
And Also Mobile Apps
Adding complexity to the goal
The client also wants mobile applications for Android and iOS to display the
content posted by the publishers. The user should be able to browse promos that
are nearest to his current location. He should be able to subscribe to shops and
browse promos of shops.
In both the website and the mobile apps, a user should be able to create an
account and must be required to authenticate before he can use the services.
The mobile apps should be delivered within 3 months.
Meet the Project Plan
The old way of doing things
In a traditional waterfall project, the plan to complete Urela will look like this:
Phase Duration January February March
Planning 1 week Analysis 4 weeks Design 2 weeks Development 2 weeks Testing 2 weeks Release 1 week
Most software development projects, if not all, have the goal of producing
working software at the end of the project.
However, you can see from the plan how much is allocated to the part where the
real action is, development.
The first three phases will be filled with the preparation and creation of
documents, which will be later on signed-‐off, as contracts to which software will
be developed and be tested against later on.
This approach has the following characteristics:
1. There is no room for mistake. Signed off.
2. There is no room for unknown, ambiguous, or changing requirements.
3. There is no room for unpredictable events that can affect the plan.
4. There is no room for feedback or client verification. Surprise at the end.
5. The chance of burning developers is very high. Because they are the one
really accountable for the working software. Meet the deadline.
6. The chance of slippage is very high. It was intended to be deterministic.
7. Poor model for long and on-‐going projects. Not sustainable.
Embracing Agile Development
A better approach to software development
Agile development aims to provide the solution to the weaknesses of the
waterfall model. It excels in doing this, and more.
The only problem is that many companies still do waterfall primarily because of
ignorance and because of resistance to change. And those that attempt to move
into agile fall victim to the incompleteness chasm, making them go back to what
worked before, the waterfall.
Here is where Eijel helps you.
We will use Eijel in developing and delivering the product for Urela. You will
learn the principles and actually do the practices of agile by using Eijel.
I am not going to bombard you with facts and info about agile. You will learn a
principle or a practice, only in the right context, and when it is needed in creating
the product for Urela.
We are now about to create our first project.
Eijel
An Anchor to Reality
Creating Your Account
Creating Your Projects
An Anchor to Reality
Eijel is an anchor to reality
Before we start using Eijel in creating the solution for Urela, I would like to
explain why I choose the approach of using a tool in teaching agile development.
The answer is simple.
Eijel is an anchor to reality.
A trainer might use index cards in explaining the concept of the product backlog
in an agile project. For him, the index card is an anchor to reality. The collection
of index cards represents a list, which is a physical manifestation of the product
backlog.
Eijel achieves this, and more.
It does not only represent a manifestation of an abstract concept, but as I have
shared earlier in the topic of the incompleteness chasm, it represents the will of
agile – the principles and practices of complete agility.
When you think of agile, you can treat Eijel as the anchor to reality, the physical
manifestation of the idea.
Creating Your Account
Create your login account
To create you account, go to http://eijel.com/signup. Eijel accounts are free.
Fill up the form and then submit.
Eijel will send you an email to confirm your registration. After this, you can login
to your account.
Creating Your Projects
Manage multiple projects
After you login in Eijel, you will see the Project Dashboard. But as you don’t have
yet any projects, it will show a message that you need to set an active project.
If you will try to explore the different pages in the site, they will give you the
same message. All the features are based in the context of an active project.
You can create multiple projects in Eijel. To create a project, go to
http://eijel.com/projects. It will initially show an empty list.
Click on Add Project and a form will show up. Name your first project as Urela –
Mobile Apps and Website, and then submit.
After saving, the newly created project will show up in your list of projects.
Note that the project automatically made you the Scrum Master. You will learn
later what it means to become a Scrum Master. You will be able to update a
project by clicking the small icon after its name.
In the next chapter, we will study more the details of a project.
Project
A Context for Everything
When a Project is Deleted
A Context for Everything
All features belong to a project
In the previous chapter we created our first project. If you now explore the other
pages in the tool, you will see that they all belong to a project.
The active project is the context of all the other pages. So if you change the active
project, the information in these pages will also change.
If you edit a project, it will show you the following form:
Here you can set the project length and the sprint length. Both of these are in
terms of number of weeks.
• Project Length – the total number of weeks allocated for the project. This
is from the start of the project to the production release.
• Sprint Length – the number of weeks per sprint. You will know later
what a sprint is.
Even though there might be some concepts that are not clear to you, like the
meaning of a sprint, you have achieved something of great importance. You have
created your first project, which is the basis of everything in Eijel.
When a Project is Deleted
Deletion of projects is allowed
You can create, edit, and delete projects in Eijel. But you have to understand
what it means when a project is deleted. As the project is the basis of all
information contained in Eijel, when you delete it, all the other information
belonging to it will be deleted as well.
Sprints
Managing all the Sprints
Updating and Deleting Sprints
Managing all the Sprints
You can create all of the sprints in advance
We have come to the part where you will be introduced to the first agile concept
you will use in delivering the product for Urela – the concept of a sprint.
A sprint is one cycle of work in agile.
The whole span of agile development consists of multiple sprints. In each sprint,
a small but complete part of the whole product is being delivered.
Think in terms of the toy Lego. It is like delivering multiple blocks of Lego at a
time, until all the blocks were delivered.
In waterfall, you deliver the complete Lego structure at the end of the project.
In agile, you deliver a few blocks in every sprint, until all blocks are delivered at
the end of the project.
The typical lengths of sprints are 1, 2, 3, or 4 weeks. You will learn more about
the details of a sprint later on. For now, you will use a 2-‐week sprint for the
product of Urela.
Edit the project and set the project length and sprint length.
You can now create all the sprints for the project. When you go to the Sprints tab,
the list will be initially empty.
Click on Add Sprint and a form will show up. Enter the sprint name, start date,
and end date.
Your list will be similar to below once you have created all your sprints.
There are six sprints in total because the project length is 3 months (equal to 12
weeks) and the sprint length is 2 weeks (12/2 = 6).
Updating and Deleting Sprints
Update and deletion of sprints are allowed
You can update and delete sprints in the list.
To update a sprint, click on the small icon after its name. This will show a form
where you can update the details of the sprint.
Similarly, you can delete a sprint. However, you can only delete sprints that have
not yet started. Once a sprint is already in progress or if it has already been
completed, it is no longer deletable.
Scrum Team
Building Your Team
When Members and Roles Change
Building Your Team
There are only three roles in a Scrum team
We have now reached the part where you will be introduced to the next
important concept in agile development, the Scrum team.
The Scrum team is a group of people accountable for delivering the product.
There are three specific roles in the team:
1. Product Owner – responsible for the product features
a. Continually re-‐prioritizes and refines the list of features
b. Actively and regularly interacts with the team
c. Reviews the result of each sprint
2. Scrum Master – responsible for applying Scrum in the team
a. Educates, coaches, and guides the team
b. Serves the team and removes impediments
c. Supports and empowers the team as it becomes self-‐managing
3. Development Team – responsible for developing the product
a. Is self-‐managing – with high degree of autonomy and
accountability
b. Is cross-‐functional – it includes all the skills necessary to deliver
the work in each sprint
c. Is multi-‐learning – each member continues to learn other
specialties
To add members to your Scrum team, go to the tab Scrum Team. Initially it will
only contain you as the Scrum Master.
Click on Add Member. This will open a form.
Enter the details of the member and click on Send Invitation. The member will
receive an email and he will be able to accept the invitation on his own Project
list.
Once he has accepted, he will show up as a member in the team.
After inviting all the members, your team will look like this:
When Members and Roles Change
You can change roles and members
There are some rules that you need to know in managing your Scrum team:
1. There can only be one Scrum Master – this is mandatory and it defaults to
the creator of the project.
2. There can only be one Product Owner – you will not be able to add more
than one product owner.
3. The development team – all developers will be under this role regardless
of skill set.
Here are the rules for changing the role of a member:
1. The Product Owner cannot be changed to other roles.
2. The Scrum Master cannot be changed to other roles.
3. A Developer can be changed to a Product Owner or a Scrum Master.
4. When the role of a Product Owner or Scrum Master has been taken away,
he will have a role of a Guest.
5. A Guest role is a read-‐only role in the project
Here are the rules for removing a member in a team:
1. The Product Owner cannot be deleted.
2. The Scrum Master cannot be deleted.
3. When a developer is deleted, Eijel smartly manages all relevant data
assigned to him.
4. A Guest can be deleted.
With the rules stated above, you can easily manage the team especially when
new members join or old members leave the team.
Product Backlog
What Needs to Be Delivered
Reorganizing the Priority
Assigning Points and Playing Poker
Viewing the Burndown Chart
What Needs to Be Delivered
A prioritized list of features
I will now introduce one of the most important concepts in agile development,
the product backlog.
If you remember, in a traditional waterfall project, most of the project time is
spent in creating documents that will serve as a contract to which a product will
be developed and tested. Participants in a waterfall project try to freeze this
document as much as possible. It was aimed to be unchanging for the rest of the
project timeline.
There is no such frozen document in agile development. Instead, we collect all
the features for the product and put them in a simple list. This list is ever
changing and very dynamic. It is always prioritized – with the most important
items on top and less important near the bottom.
This list is called the product backlog.
It contains everything that the business thinks it needs for the product. By design
it supports a sustainable and continuous development – as you can always add
and remove and shuffle items in the list. It is in stark contrast to the frozen
document of waterfall.
You will appreciate and understand it more, when you see it in action.
We will now create the product backlog for Urela.
Adding user stories
For a new project, your product backlog will be initially empty. The whole Scrum
team has capability of adding user stories in the list.
You can access it at the Product Backlog tab.
To add a story, click on Add Story and a form will show up.
Enter the title and category for the user story. Categories that you add will be
available next time you add new stories.
After adding several use stories, your Product Backlog will look like this:
Reorganizing the Priority
You can easily reorder the product backlog
One of the important characteristics of the product backlog is that it is always
prioritized. The most important features are always on top and the less
important are near the bottom.
To achieve this, the list should be easy to re-‐arrange.
With Eijel, you can easily reorder the stories in the Product backlog by drag-‐
and-‐drop. This feature is a delightful way of organizing the stories.
Here is how the drag-‐and-‐drop action looks like:
The list automatically saves itself after the reorder is done.
Assigning Points and Playing Poker
Points represent level of complexity
To update a user story or to set its points, click on the icon after the story’s title.
A form will show up after clicking the icon.
Points represent the level of complexity of a user story. By assigning points to all
of your user stories, you can have a measure of the total points for the whole
project. This will help your team later on when predicting how much you can
complete in each sprint, using your previous achieved points.
Here is a suggested approach for assigning points to each of your story:
1. Go through all of your user stories and try to find the simplest as well as
the most complex story.
2. Assign 1 point to the simplest and 5 points to the most complex.
3. Using the two user stories above, assign points to all the other user
stories.
4. If you find a user story as vague, unclear, or extremely complex, assign the
points 100 to it.
5. Repeat the re-‐assignment of points until all are within the 1 to 5 ranges.
Clarify later all those that have a 100 points by checking with the Product
Owner or Scrum Owner.
You are now familiar on how to create and update user stories for your product
backlog.
Assigning points by playing poker
Assigning points is a team activity. Try to include everyone present in the
development team when doing the assignment.
One tool used for this collaborative work is playing poker.
Here is how it works:
1. Give each member of the team five cards containing the following
numbers: 1, 2, 3, 5, and 100. 100 represents complex, unknown, or
ambiguous user stories.
2. The Scrum master will read each of the user stories, give them description
and details so they are clear to all developers participating in the playing
poker.
3. Each developer will assign a number to the user story and will place the
card for that positioned upside down.
4. The Scrum master will ask everyone to reveal their number once all have
placed their cards.
5. If all cards have the same value, that will be the number for the user story.
If there is a large deviation, the Scrum master can ask for an explanation
why a developer thinks differently from others. The developers will
repeat again the process until a consensus is reached.
6. This way, all the user stories will have points.
One common question is – how do you perform playing poker in a distributed
team?
Eijel has a solution for this. You can do playing poker online using Eijel.
Go to the Playing Poker link in Eijel and you will see a screen containing all of the
developers.
The X in the screen means that the developer has not yet assigned a number to
the user story.
There are four buttons in the screen. They represent the following:
• Estimate – click this if you want to assign a number to the user story
• Refresh – this will refresh the page to show the latest state of the cards
• Reset – this will reset your current assigned number to the user story
• Reveal cards – this will reveal the values of all the cards. A reveal will only
happen if all the cards have a check mark, meaning, all have assigned their
numbers
When you click the Estimate button, a form will show up where you can assign
and submit the number.
The numbers above are the complete standard numbers used for playing poker.
Click Submit Estimate when you have chosen a number.
After every estimation the Scrum master updates the story with the points for it.
Viewing the Burndown Chart
How much work is left for the project?
You will now be introduced to one of the most important charts in agile, the
burndown chart.
It typically shows the ideal as well as the actual completion of items. For a
product burndown chart, it represents the completion of points.
It is a tool for knowing how the team performs – whether they are delayed, on
track, or ahead of work.
Here is a sample burndown chart for Eijel:
Wiki
Maintaining Living Documents
Uploading Images
Maintaining Living Documents
Documentation exists
Documentation is important, regardless of the chosen methodology. But there is
a big difference between agile and waterfall documentation – documents in agile
are living and dynamic instead of dead and static.
In waterfall, changes to the documentation, once signed-‐off, and once
development has started, is not acceptable. This is in stark contrast with agile
where changes are welcomed especially if they bring business value.
To document in agile, you will not use the tool well known in waterfall, Word.
You are also not going to document everything, only the essentials.
You will use a tool called a wiki.
This format of documentation has the following benefits:
• Anyone in the team can update the document
• The document is available online and can be accessed anywhere, anytime
• It is a living document and can always be corrected and enhanced
Eijel has a built-‐in wiki to make your documentation simple and easy. We value
documentation a lot such that we made all user stories in the product backlog
automatically have a corresponding wiki for it.
Each of these wiki pages also has acceptance criteria. By automatically
documenting each – there is no way ambiguity can stay on a user story. If a story
has a complex business rule, all you have to do is put the information in its wiki
page.
Developers will benefit from such wiki page. They can use the acceptance criteria
in creating the automated tests in their code.
Here is how a sample wiki page with acceptance criteria looks like in Eijel:
If your documentation does not map to any specific user stories, you can make a
wiki for it. We call this kind of wiki an article.
Go to the Wiki of Eijel and you will see the second tab for articles:
Uploading Images
You can add images to your wikis
Most of the time you will need to use images in your documentation. To make
things simple and easy for you, Eijel included a tool for uploading images that
you can use in your documentation.
Go to the third tab of the wiki tool and you will see the place for uploading
images.
Initially your list will be empty:
Click on New Photo Upload and a form will show up. You can now upload a
photo.
Your uploaded photo will show up afterwards in your list.
Sprint
How Much Work Can Be Done?
Doing the Actual Work
Progressing the Tasks
Closing a Sprint
Viewing the Burndown Chart
How Much Work Can Be Done?
The challenge of estimation
One of the difficult tasks in waterfall is estimation. Sometimes you would have to
prepare estimates for work that spans several months. Depending on the project
complexity, these estimates could be wrong by days or weeks.
Estimations are also needed for agile development. But you will rarely estimate
time allocation for work that spans 4 weeks. The shorter the span of time, the
more accurate the estimates are.
One of the questions you will face in every sprint is how much work can be
done? Since the sprint consist only of a few weeks, this is not very difficult.
Eijel has a built-‐in tool that can make this even easier. It’s called Capacity
Calculation and it will help you produce highly accurate estimates.
It is accurate because it tries to be empirical as much as possible.
With Capacity Calculation, you will be able to get accurate answers to the
following questions:
1. How much development hours will the team produce in the next sprint?
2. How much hours will the team spend on meetings?
3. How much hours will the team spend on bug fixing?
4. How much hours will the team be off?
You get the answers above by following these steps:
1. Go to Capacity Calculation in Eijel
2. The tool will show each of the developers in the team
3. You will ask each developer the following questions
a. Do you have any planned leaves in the next sprint?
b. How much development time will you allocate next sprint?
c. How much bug fixing time will you allocate next sprint?
d. How much meeting time will you allocate next sprint?
4. Check the calendar for any holidays in the coming sprint. Add the hours
to the Hours Off for each developer.
5. Enter the values for each developer
6. Once all the values are entered into the tool, you will see the total
development time for the team.
You know now that your team can allocate 315 hours to development in the next
sprint.
You will now determine the actual work that can be done for the 315 hours.
Doing the Actual Work
What actual work can be done?
In the previous lesson we were able to determine that we have 315 hours
allocated for development in the next sprint.
We will now determine what we can we can achieve with that 315 hours.
It is time also to introduce an important concept in agile development, sprint
planning.
Sprint planning consists of two parts:
1. Part One – the goal is to determine what will be included in the sprint.
This is done by the Product Owner, with the help of the rest of the team.
2. Part Two – the goal is to determine the number of stories the
development team can deliver and how they will deliver them. The
development team does this.
The output of the sprint planning is called the sprint backlog. It is the list of
stories, and their tasks, that must be completed in the sprint.
Sprint planning is seamless and very easy in Eijel.
For the first part of sprint planning, the Product Owner adds stories to the
sprint by following these steps:
1. Go to the product backlog
2. Add a user story to the sprint by clicking its Start link
3. Once the story has been started, its status will change into In Progress
4. Start all the other stores needed for the sprint
5. Verify that the current sprint has started in the Sprints tab
6. You can now view your sprint backlog in the Sprint Backlog page
For the second part of sprint planning, the development team determines the
actual number of stories they can deliver by following these steps:
1. Notice that each story takes 0 hours to complete. This is because they do
not have any tasks
2. To add tasks to a user story, click on Add Task. A form will show up where
you can enter the title of the Task and its estimate in hours.
3. Once you have completed adding tasks to all of your user stories, your
Sprint Backlog will look like this:
4. You can easily see the total number of hours your team will need to
complete the sprint. The total hours for done and in-‐progress tasks are
also shown. The sprint backlog shows that the team can achieve this
amount of work for the sprint.
At this point, the development team can inform the Product Owner that it can
add more stories into the sprint. They will do this until they have reach a
number where it matches the allocated development time.
Progressing the Tasks
Easy drag-‐and-‐drop
In the previous lesson we have determined the contents of the sprint backlog.
We will now look into the actual progressing of the tasks.
If you have observed, we initially did not assign tasks to developers. These tasks
will be assigned in real-‐time. When they are about to be done. This is a pull
model as compared to the push model of waterfall. The developers assign the
tasks to themselves. This shows the spirit of collective ownership in an agile
team.
Assigning a Task
To assign or edit a task, click the icon after the title. This will show a form.
Every tasks has a status:
1. Todo – the task has not yet been started and has not yet been assigned
2. In Progress – the task is being worked by a developer
3. Done – the task has been completed by a developer
To move a task from one status to another, just drag and drop the item.
Once your team has started working on the tasks, the sprint backlog will be
similar to this:
You can easily see the number of hours for Todo, In Progress, and Done.
Closing a Sprint
Closed sprints can be viewed
Your development team will give its best in completing all user stories in the
sprint. Regardless if all stories were completed, at the last day of the sprint, you
would have to close the sprint. This follows the time-‐boxed nature of activities in
agile development.
When your team has completed all the tasks for the user stories, the stories will
show up as Done in the Product Backlog.
You can end your Sprint by clicking End at the Sprints tab.
After clicking End, the Sprint will be marked as Done.
You will still be able to view previous Sprints by clicking View. This way you can
know what tasks were included and who worked on the tasks of previous
sprints.
Viewing the Burndown Chart
How much work left for the sprint
At any time during the sprint, you will be able to view the burndown chart for
the sprint. This chart represents the remaining hours left to be completed for the
sprint. It can also show you how your team is performing against the ideal
burndown.
Bug Tracker
Managing Project Defects
Managing Project Defects
Defects are normal
Defects can occur in any project, regardless of the methodology followed during the development. We consider them as normal and accept them as part of life.
For this reason, we gave our best in creating what we believe is the currently best defect tracking tool in existence. And this tool comes as part of Eijel.
Introducing the Eijel Bug Tracker.
At one glance, you can easily know the state of your project with regards to defects. You know right away the following important statistics:
• Count of Open defects • Count of Show Stopper open defects • Count of High priority open defects • Count of Medium priority open defects • Count of Low priority open defects • Count of Unassigned defects • Count of Fixed defects • Count of Ready for Retest defects • Total number of defects for the project
The Eijel Bug Tracker is a grand example of opinionated software. It will not allow you to sort the columns, as it sorts itself on its own.
It follows the following rules
1. The list is first sorted based on importance – with the highest severity on top. It follows the following order: Show Stopper, High, Medium, and Low.
2. The list is sorted afterwards based on progress – with the newest on top. It follows the following order: New, Assigned, In Progress, Fixed, Ready for Retest.
3. Closed issues are always at the bottom.
Once you have experienced this smart auto sorting, you will never come back to other defect tracking tools.
The bug tracker has also one of the best search functionality among tools – as most of the time – developers are searching for specific issues and do not want to see the whole list. Often they just want to see the issues that are assigned to them or the issues they have worked on.
By clicking on the Search Icon, the search functionality will show up:
With this feature, you will be able to filter on any of the columns in the bug list.
The best features of the Bug Tracker are not limited only on the list and on the search – when you click the title of the defect, it will bring you to a wiki page exclusive for that defect.
In our experience, the true value of a defect tracker comes from user interactions that happen within the defect. This means communication and clarification by means of comments and attachments, all fully supported within the tool.
When you click on one of the issues, you will see its wiki.
The developers involved in testing and fixing can easily attach files and create threaded conversations in this wiki page.
Software Engineering
Serve the Developers
The Value of Quality Code
Serve the Developers
A servant leader is not a boss
In agile development, much emphasis is placed on empowering the development
team. Because at the end, they are the one really creating the product.
The product will be a creation of the development team.
They deserve this credit.
The Scrum Master helps the team achieve their best by removing any
impediments that can block them.
Eijel helps in this goal by providing within the tool a means for managing
impediments.
You will be able to add, edit, and set the status of each impediment. Anyone in
the Scrum team can add impediments.
Notice that they are not assigned to a name, as it is implied that the Scrum
Master will handle the impediments, with help from within and outside the team.
The Value of Quality Code
Reduce undone work
Depending on the maturity and skills of the developers, they would have some
undone work.
Remember that the goal of every sprint is to product a complete set of features.
These features should be potentially shippable to production.
However, there are times when developers can’t follow all the requirements to
produce the level of quality set by the team. These things are called undone
work.
Eijel has the feature for managing undone work.
Notice that the items are not assigned to any specific developer. This is because it
is implied that it is everybody’s business to make sure his or her quality of work
does not include any undone work. This is in the spirit of continuous
improvement.
Conclusion
A Promise Kept
Succeeding in Your Projects
A Promise Kept
You can only master the things you actually do
I have given you four promises at the start of the book.
I promised you that:
1. You will know how to do agile.
2. You will know how to achieve complete agility.
3. You will know how to master agile.
4. You will succeed in all of the above if you give the effort in actually doing
At this part of the book, you know how to do agile.
You know how to actually do it using Eijel.
You have a mental context, an anchor to reality when you think of the following
words:
• Product Backlog
• Sprint
• Scrum Team
• Sprint Planning
• Sprint Backlog
• Impediments
• Undone Work
• Burndown Chart
• And other agile concepts
You can only master the things that you actually do.
By giving effort in the part of actually doing, you will gain mastery.
Succeeding in Your Projects
Create your free Eijel account
I created Eijel with the goal of creating the simplest tool that manages agile projects from vision to product release.
I now invite you to give Eijel a try in actually doing your agile projects.
Eijel is free.
By using the principles and practices you learned in this book, and by actually doing agile with the help of Eijel, you will succeed in your software development projects.
Thank you for taking this learning journey with me.
If you would like to learn more, you can visit my blog at:
http://completeagility.com
You can see my contact info at:
http://eijel.com/contact
Feel free to add me in LinkedIn at:
http://sg.linkedin.com/in/dondonvizcayno