I have been working on agile projects for many years. A few years ago, I had an idea: it would be great if ServiceNow could support story estimation during Backlog Refinement or Sprint Planning meetings using Scrum Poker.
I started working on it and finished the first version. At that time, it was mostly a way for me to improve my ServiceNow skills, so it never went into production. I put the project aside for a while (there were always other, higher priority hobby projects to do 🙂), but I always knew I wanted to develop a truly usable Scrum Poker tool.
Then, Next Experience and UI Builder arrived. I was thinking about how to build the solution there. I had two technical expectations:
-
I did not want to use any new tables for the solution.
-
I wanted to use WebSocket-based communication to ensure a great user experience.
I spent a lot of time trying to implement WebSocket-based communication between the backend and the frontend on the platform, portal, and workspace. I wanted a solution that was not connected to a specific table, but unfortunately, I was not successful.
The ServiceNow AMB (Asynchronous Message Bus) is a relatively restricted solution. Because of these limitations, I decided to put the project aside once again.
Build With Build Agent challenge
Then came the #BuildWithBuildAgent challenge. By this time, I had let go of the idea of not using any tables. In my experience, the number of custom tables is usually not a problem anymore.
I was very curious about what the Build Agent could do and how I could use it. So, I had an idea: I would use the Build Agent to finally create a production-ready version of my Scrum Poker app.
I set the following requirements for the solution:
-
The feature needs to connect to the Agile Development module, which is still available and supported.
-
I needed two personas: the Scrum User and the Scrum Master.
-
WebSocket was a 'must-have' feature. I did not want to remove it because it allows real-time interaction and increases the user experience.
-
The number of tables did not matter anymore.
-
I wanted a responsive design that looks like the standard ServiceNow UI.
-
The process should be simple and follow the Scrum methodology.
So, I knew what I wanted, but I was open to changes, especially if the Build Agent suggested something different.
As a first step, I watched Earl's video because I was a beginner in this area. I am still not a 'pro' today, but I can say that I have seen a few things since then.
I took a PDI (Personal Developer Instance) and started. I wrote my first prompt, which looked like this:
Spoiler
Build a new application and call it SN Scrum Poker.
The solution will be an interactive "game" for the story estimation.
PERSONAS:
- Scrum master (role: scrum_poker_scrum_master)
- Scrum user (role: scrum_poker_scrum_user)
PROCESS:
The process is the following:
1. Scrum master initiates a poker event, and the Scrum users can join the event. The join procedure can be as simple as possible. You can use a unique code or QR code.
2. The joined users or at least the number of joined users appear on the screen.
3. Scrum master opens a story from the rm_story table in ServiceNow and start the poker round
4. Scrum users can join the poker event
5. Scrum master starts the estimation. When it happens poker cards appear on the screen of all attendees. The poker cards have to be ServiceNow styled. We can use the Fibonacci number on the cards. The biggest number is 20. There should be a card which can be used if the user can't select a number.
Each user has 10 seconds to select a card. A countdown timer appears on the screen.
6. when the time is up, the Scrum master clicks a button and the result is shown on the screen of all users
7. After the decision of the selected point the Scrum Master select the card and this point is written to the selected story record. (table: rm_story, field: story_points)
FRONT-END:
Two front-ends has to be created:
- One for the Scrum master.
- One for the Scrum users. This layout has to be responsive, so it should look good on mobile screen as well.
STYLE:
The style of both pages should be modern and responsive. You can add some poker related styles as well.
IMPLEMENTATION RULES:
- Use Scripted REST API for the Client and Server communication
- ServiceNow's server-side JavaScript engine doesn't support the ES6 import/export syntax.
- nowDateTime is not allowed in scope application. Use GlideDateTime instead: new GlideDateTime().getDisplayValue()
AUTOMATION:
Use record watcher or the ServiceNow built-in websocket to make the front-end as interactive as possible.
Take care that multiple users vote (select a card) at the same time, so the solution has to support the concurrent action process.
OTHER TECHNICAL RULES:
- If somebody accidentally logs out or has internet connection issues the user can rejoin the active session.
OTHER PROCESS RULES:
- It should be possible to execute multiple Scrum events at the same time by different groups.
To be honest, the prompt above is not 100% the original one. This is a version that I modified and refined several times. I actually restarted the whole process a few times. 😅
The Build Agent processed the prompt. It ran for quite a long time, and finally, it finished. It gave me two links to test the solution.
Of course, it did not work at first, so I started a long "conversation" started with the Agent. 🙂
Chatting with the Build Agent
Now, I would like to share my experience regarding the conversation with the Build Agent. We exchanged about 100 messages before I could finally say: "I have a working version."
A small part of these messages (approximately 10%) was not useful. Sometimes this happened because my prompt was not good enough. Other times, the Agent wanted to do things differently than I requested. For example:
I asked the Agent to modify one specific feature and clearly told it not to change anything else. However, it modified other parts of the code as well, which broke the application.
Communicating with the Agent was not always smooth. I received HTTP errors very often, sometimes many times in a row. Of course, I know this is a PDI, so I cannot expect perfectly stable performance.
In one case, the HTTP error became constant, so I had to release my PDI and request a new one. After that, it worked again.
There were also times when the Agent started processing my prompt, but it failed with an HTTP error in the middle of the it. These failed attempts counted toward my 10-prompt limit. At one point, my 10 prompts were gone, even though I only had 2 or 3 useful messages. The others were all lost because of processing errors.
One time, I got quite frustrated and told the Agent that it was not fair to use up my 10 prompts with almost zero value. I asked it to reset my counter. The AI apologized many times and agreed that my complaint was valid. It said it would reset the counter. Of course, it did not happen. 🙂
There was also a case when I used up my 10 prompts and decided to release my PDI. However, after that, I could not request a new one for several hours.
Overall, I would say that I faced many challenges along the way. Some of these were my own mistakes, and others were caused by the technology itself, but the final result is promising.
That is enough about topic "communication" for now, let's get back to the project.
Core Configuration
Roles
The Build Agent created the roles exactly as described in my prompt. It was interesting that although scrum_master and scrum_user roles already exist in ServiceNow, the system did not ask if I wanted to use them. It simply created new ones without asking.
Tables
I did not ask for specific tables in the prompt. Instead, I described the process in detail and let the Build Agent create the tables based on its understanding. This part went quite well. It built a logical and well-structured table system.
Back-end logic
In my original prompt, I asked the system to create Scripted REST API endpoints for the back-end operations. The Agent created these correctly, and they were usable from the start. Of course, I had to modify them manually later a bit.
Automation
I described how the system should behave regarding server-side events and the use of WebSockets (AMB). The Build Agent could not fulfill this request. At first, it did not use WebSockets at all, instead, it tried to use simple polling to monitor back-end events.
I decided to wait as long as possible without touching the code, trying to solve the problem only through prompting. I tried many different prompts, but the Agent could not produce a working feature. I had to explain in detail, using example code, how AMB works. After that, the result was better, but it still did not work as I expected.
I used at least 30 prompts for the AMB issue, but in the end, I had to finish it manually.
Style
I was not specific enough about the style in my first prompt, and the results reflected that. The AI used general design elements. However, the responsive interface was created successfully and worked quite well from the very beginning.
Overall, I can say that the processing of the first complex prompt was quite successful. Even though some solutions did not work, the Build Agent was able to build the basic structure of the application.
The code base
I have mixed feelings about the quality of the code. Some solutions were very good, while others did not follow best practices. For example, sometimes the Agent used the getValue() function for getting a field value, and other times it just used simple dot-walking for the same purpose. It was strange to see different methods for the same task.
As I sent more prompts, the code became more complex. After a while, it was very difficult to understand. In the beginning, I tried to fix everything using only prompts, but I eventually gave up. I felt that no matter how I wrote the prompt, we were not making progress.
So, I started to find the bugs manually. First, I just read the code, but later I had to use debugging. The solution was so complex and involved so many different files (especially the AMB related features) that it was hard to see the big picture just by reading the code.
When I found the root cause of a bug, I asked the Agent to fix it. Sometimes it worked, but other times I just gave up and fixed it myself.
I would like to highlight that ServiceNow IDE helped me a lot to find the relevant part of the source code.
The Solution
In this section, I will show the available features of the solution.
The Build Agent created two UI Pages: one for the Scrum Master and one for the Scrum Users.
The Scrum Master starts the process and has two options:
-
Start a new Scrum session.
-
Continue a previous session.
When a session is created, the system automatically generates a code. The Scrum Users can use this code to join. If the Scrum Master decides to continue an existing session, they must use the same code. You can see the two interfaces below:
After the Scrum Master starts the session, the following layout appears:
The screen includes these key elements:
-
Session name
-
Session code
-
WebSocket connection status (established)
-
List of stories with a simple search feature (there is not additional filter in this version)
-
List of attendees (the list refreshes automatically when a user joins the session)
The Scrum User interface is simpler and contains less information. This is because my idea or main concept was that story estimation happens during a meeting where the Scrum Master's screen is visible to everyone.
After logging in, the Scrum User sees a waiting screen. As soon as the Scrum Master selects a story, it will appear on the user's screen:
Waiting screen
A story is selected
The Scrum Master can see all the story details, and the team can review them together. Then, the Scrum Master can start the voting by clicking the 'Start voting' button.
Once the 'Start Voting' button is clicked, team members have 20 seconds to cast their votes.
In case of any issue, the Scrum Master can decide to restart the voting.
Once the Scrum User selects a point, the following screen appears, but the timer is still ticking:
When there is at least one vote, the Scrum Master can reveal the results, and then it is time for the team to discuss the estimate.
The team finalizes the estimate, and the Scrum Master saves the points to the selected story. Alternatively, the Scrum Master can decide to restart the voting from this screen as well.
Once 'Set Story Point' is clicked, the story is updated in the background. Then, the waiting screen appears again for the Scrum Users, and the team can move on to the next story.
The following video demonstrates how the solution works using some users at the same time:
Closing Thoughts
This challenge was a great journey for me. I learned a lot and gained valuable experience. I can say that I now somewhat understand how the Build Agent works. The road to the final solution was quite bumpy, and I faced many smaller and larger difficulties along the way.
My original plan was to let the Build Agent do as much of the development as possible. In my opinion, this was quite successful. About 85-90% of the final code is AI-generated. I created the images, made some small changes to the design, and fixed the code in several places.
Most of my time was spent finding the root causes of bugs and then either asking the Agent to fix them or fixing them myself.
Obviously, the solution is not finished. I see a lot of potential in this project, and we will see if I have the opportunity to continue it in the future. (After all, as I mentioned at the beginning of this post, my long-term plan was always to create a usable one! 🙂)
In any case, I would like to share the codebase with the community. If you like it and want to be a contributor, the opportunity is there!
In conclusion, I think the Build Agent is a step in the right direction. You can already do amazing things with it. Like every new technology, it has its initial difficulties in the beginning, but I believe it will overcome them and become better and better over time.
